AUR connection issues (EOF/TLS errors)

Robertderidder · 2026-06-02 13:35:50

Hello, I keep having trouble with the AUR. Even though status.archlinux.org reports no outage. I keep getting an EOF error. Is this something I should fix on my side? Is it still a result of the DDOS attacks? Do more people have this problem?

seth · 2026-06-02 13:51:14

If the problem remains report the problem along your WAN IP to accountsupport@archlinux.org - you're probably running into the DDOS mitigation

gromit · 2026-06-02 14:21:59

Yes that is correct, the AUR should overall be up and running

Lenry · 2026-08-18 18:19:48

I'm getting the same error message, but it seems like it depends on your provider. I have two WAN connections, from the hungarian Digi network it works, but from the hungarian Telekom it doesn't

raggerv8 · 2026-08-18 19:54:45

I was even on the AUR earlier today and clicked “view changes” on a package and it failed to load. Now I have been unable to reach the AUR for a few hours.

Last edited by raggerv8 (2026-08-18 19:55:01)

seth · 2026-08-18 20:06:21

https://status.archlinux.org

vicbis · 2026-10-04 23:54:55

This is happening with me. It's rather annoying since I have to use a VPN get access to the AUR repository.

1: Please don't point me at "https://status.archlinux.org" because it states it is up (and I still cannot access)
2: My external IP address (that I usually use) is 138.217.204.154
3: Since from October 1 at approx 00:00 (GMT) it's been blocked, before that everything was operational.
4: I don't know how the 'bans' work but the only thing I installed and used is 'traur scan'
5: This link (that I was sent) https://gitlab.archlinux.org/archlinux/ … ecture.png does not provide any info on why my IP address is 'banned'
6: As for the '1 hour' ban, well it's now been 4 days.
7: No, there are no automated scripts that accesses the repository, I do updates manually on weekdays and that's only usually a few packages per day and been doing this for a number of years.
8: No, no one else accesses the repository at this IP address as 1: All other staff are using Windows and 2: other linux related uses here (at work) are Ubuntu machines.
9: It's nothing on my laptop as if I do AUR updates from an alternative IP address I have no problems.
10: The non-AUR updates are not affected.

vicb@ava [ ~ ]$ openssl s_client -tls1_2 -connect aur.archlinux.org:443 -servername aur.archlinux.org </dev/null 
Connecting to 209.126.35.78
CONNECTED(00000003)
4054FC4B607F0000:error:0A000126:SSL routines::unexpected eof while reading:ssl/record/rec_layer_s3.c:698:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 0 bytes and written 222 bytes
Verification: OK
---
New, (NONE), Cipher is (NONE)
Protocol: TLSv1.2
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : 0000
    Session-ID: 
    Session-ID-ctx: 
    Master-Key: 
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1791156098
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)
    Extended master secret: no
---
4054FC4B607F0000:error:0A000197:SSL routines:SSL_shutdown:shutdown while in init:ssl/ssl_lib.c:2804:

Whereas from another server:

 vicb@<redacted incase of this ip/domain gets banned as well> [ ~ ]$ openssl s_client -tls1_2 -connect aur.archlinux.org:443 -servername aur.archlinux.org </dev/null 
Connecting to 209.126.35.78
CONNECTED(00000003)
depth=3 C=US, O=Internet Security Research Group, CN=ISRG Root X2
verify return:1
depth=2 C=US, O=ISRG, CN=Root YE
verify return:1
depth=1 C=US, O=Let's Encrypt, CN=YE1
verify return:1
depth=0 CN=aur.archlinux.org
verify return:1
---
Certificate chain
 0 s:CN=aur.archlinux.org
   i:C=US, O=Let's Encrypt, CN=YE1
   a:PKEY: EC, (prime256v1); sigalg: ecdsa-with-SHA384
   v:NotBefore: Aug 12 18:47:39 2026 GMT; NotAfter: Nov 10 18:47:38 2026 GMT
 1 s:C=US, O=Let's Encrypt, CN=YE1
   i:C=US, O=ISRG, CN=Root YE
   a:PKEY: EC, (secp384r1); sigalg: ecdsa-with-SHA384
   v:NotBefore: Sep  3 00:00:00 2025 GMT; NotAfter: Sep  2 23:59:59 2028 GMT
 2 s:C=US, O=ISRG, CN=Root YE
   i:C=US, O=Internet Security Research Group, CN=ISRG Root X2
   a:PKEY: EC, (secp384r1); sigalg: ecdsa-with-SHA384
   v:NotBefore: May 13 00:00:00 2026 GMT; NotAfter: Sep  2 23:59:59 2032 GMT
 3 s:C=US, O=Internet Security Research Group, CN=ISRG Root X2
   i:C=US, O=Internet Security Research Group, CN=ISRG Root X1
   a:PKEY: EC, (secp384r1); sigalg: sha256WithRSAEncryption
   v:NotBefore: May 13 00:00:00 2026 GMT; NotAfter: Sep  2 23:59:59 2032 GMT
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIDjzCCAxagAwIBAgISBT72njVzlvin4/JLjQW3CEcnMAoGCCqGSM49BAMDMDMx
.
. (etc)
.
.

If it comes to It, I'll just have to use a VPN … but that's not the point.

Pillendreher · 2026-10-05 04:31:55

vicbis wrote:

4: I don't know how the 'bans' work but the only thing I installed and used is 'traur scan'

Been suffering from the same issue since Thursday and I too installed traur on my Desktop system. When I tried to do the same on my laptop an hour later, I could not access aur any longer. Spent an hour trying to figure out if Adguard Home was responsible before I stumbled onto this thread. The ban on my external IP (83.164.61.***) has not been lifted as of yet. Maybe the initial traur scan triggered some sort of rate limit?

seth · 2026-10-05 06:49:58

Why would anyone point out status.archlinux.org when that's not an ongoing situation?
(Though as you can see the AUR has been a bit spotty the last few days)

Don't post your WAN IP into the public, https://www.openstreetmap.org/#map=18/- … 144.962062
Report it to accountsupport@archlinux.org

traur (written by claude) polls the AUR to query metadata, might have gone rogue.
=> https://wiki.archlinux.org/title/Wireshark

vicbis · 2026-10-05 11:05:06

1: It's got nothing to do with AUR being down. I can set an 'at' job to fire at exactly the same time and on two different servers at two different IP addresses and still get the same results in my post.
2: Yes that's the Lonsdale street telephone exchange — I'm not there.
3: Yes I've sent an email to 'accountsupport@archlinux.org ... and basically got no useful information from them.

From: "XXXXXXXX XXXXXX (@gromit)" <gitlab@gitlab.archlinux.org>
Reply-To: Arch Linux / Service Desks / Account support <incoming+6-46XXXXXXXXXXXXXXXXXXXXXXXX-XXX@gitlab.archlinux.org>
To: <me>
Subject: Re: AUR TLS handshake dropped from XXX.XXX.XXX.XXX (0 bytes read)

New response for issue #XXXXX:

Author: XXXXXXXXX XXXXXX 

Hello,

that is most likely due to rate-limits being exceeded by the IPs in question, do you have anything that programatically accesses our services or just a lot of users? :thinking:

If you're curious on why this happens, here is is diagram for our setup: https://gitlab.archlinux.org/archlinux/infrastructure/-/blob/b727817071794eeea73bd467467c8e7f1bd566d8/docs/graphs/HAProxy-service-architecture.png 

Cheers,
XXXXX

I've replied in detail October 2, but to no avail. The silence is deafening and as I type now it's still blocked (nearly 5 days now).

4: I'm not going to test with wireshark as that will most likely put another (permanent) ban on whatever IP address I'm going to use.

5: So much for AI written code. Was it fully tested, probably not.

5: My solution:

vicb@ava [~] sudo pacman -R traur # AUR may flag a DDOS attack at AUR from here therefore deleting.

seth · 2026-10-05 12:07:46

1: It's got nothing to do with AUR being down. I can set an 'at' job to fire at exactly the same time and on two different servers at two different IP addresses and still get the same results in my post.

Yes, that's why I don't understand why you'd preemptively warn people to no bring it up - the entire point is just insane.

4: I'm not going to test with wireshark as that will most likely put another (permanent) ban on whatever IP address I'm going to use.

Wireshark is going to do exactly nothing like that - it allows you to monitor your traffic to see whether and what is currently banging the AUR from your host.
You can try and see whether that's actually traur but even if you're not risking that, you can passively check that this is currently not happening.

If you're behind a CGN it's also possible that this is completely unrelated to your system - have you tried to restart your modem to hopefully get a different IP from your ISP?

rharish · 2026-10-09 20:34:40

Same issue here from Switzerland, with my home internet, but it works somehow from my mobile phone's carrier's internet (via an Android hotspot). I'm behind CGNAT, if that helps.

Also, only HTTP(S) seems to be blocked, while SSH works. So a

git clone aur@aur.archlinux.org:PKG.git

works via my AUR SSH key (I maintain a few AUR packages), while

git clone https://aur.archlinux.org/PKG.git

doesn't.

Last edited by rharish (2026-10-09 20:38:04)

Akela · 2026-10-10 19:43:55

Hello,

I am experiencing the exact same TLS connection error (`unexpected eof while reading`) when trying to access `aur.archlinux.org` via browser or `yay`.

Here are my connection details:
- **ISP:** AS8193 ("Uzbektelekom" Joint Stock Company)
- **IP Range (Subnet):** 213.230.64.0/18 (Announced: 213.230.78.0/24)
- My IP - 213.230.78.xxx
-**Location:** Uzbekistan

**Diagnostic details:**
- `curl -v https://aur.archlinux.org` fails with `TLS connect error: error:0A000126:SSL routines::unexpected eof while reading`.
- Handshake drops immediately at `Client Hello` stage.
- Connections work fine when using a VPN or an alternative network interface.

Could you please check if our ISP's IP range was affected by rate-limiting or DDoS mitigation filters?

Thank you!

Akela · 2026-10-13 22:27:12

gromit wrote:

Yes that is correct, the AUR should overall be up and running

Hello,

I am experiencing the exact same TLS connection error (`unexpected eof while reading`) when trying to access `aur.archlinux.org` via browser or `yay`.

Here are my connection details:
- **ISP:** AS8193 ("Uzbektelekom" Joint Stock Company)
- **IP Range (Subnet):** 213.230.64.0/18 (Announced: 213.230.78.0/24)
- My IP - 213.230.78.xxx
-**Location:** Uzbekistan

**Diagnostic details:**
- `curl -v https://aur.archlinux.org` fails with `TLS connect error: error:0A000126:SSL routines::unexpected eof while reading`.
- Handshake drops immediately at `Client Hello` stage.
- Connections work fine when using a VPN or an alternative network interface.

Could you please check if our ISP's IP range was affected by rate-limiting or DDoS mitigation filters?

Thank you!

maksverver · 2026-10-18 02:32:37

Same here from Switzerland. I am posting this message from a Tor relay because I cannot even access this forum from my residential IP.

Can you guys stop messing around with the DDoS mitigation that is clearly blocking real users? And no, I'm not spamming Arch Linux with requests. The error is on your end.

Last edited by maksverver (2026-10-18 20:13:39)

seth · 2026-10-18 07:01:00

You stand a better chance getting attention by contacting accountsupport@archlinux.org - ideally after calming down.
I'm not sure to what extent this thread gets tracked.

I cannot even access this forum from my residential IP

The services also fail from other clients behind the same WAN IP?
(To rule out MTU issues etc.)

rant

https://bbs.archlinux.org/viewtopic.php?id=315192
https://en.wikipedia.org/wiki/Anubis_(s … _criticism

echo foo | curl -F 'file=@-' https://0x0.st

You'll have to understand that the internet is currently fundamentally broken and will at least remain to be until the cash-flow of Damokles inevitably drops.
Keep in mind that nobody ever owed you the internet and that if it becomes unaffordable (or unprofitable, in business cases) to run, will shut down and then will only be the hyperscalers scraping their own databases into eternity.

ewaller · 2026-10-18 15:39:42

maksverver wrote:

Same here from Switzerland. I am posting this message from a Tor relay because I cannot even access this forum from my residential IP.
Can you guys stop fucking around with the obvious bullshit DDoS mitigation that is clearly blocking real users? And no, I'm not spamming Arch Linux with requests. The error is on your end. Fix your shit.

Would you send me a private message with your IP address, I will check it out.

stronnag · 2026-10-18 17:00:57

Yet another data point:

For some time now, I'm unable to connect reliably to any archlinux.org property over IPv6. IPv4 works perfectly, IPv6 works everywhere else (apart from *archlinux.org, where it fails probably 90% of the time).

Routing:

$ tracert6 -n  aur.archlinux.org # UDP, default
traceroute to aur.archlinux.org (2604:cac0:a104:d::2) from 2a02:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx, 30 hops max, 60 bytes packets
 1  2a02:xxxx:xxxx::x  1.757 ms  1.912 ms  1.755 ms
 2  2a02:8010::156  26.905 ms  27.638 ms  28.199 ms
 3  * * *
 4  * * *
 5  * * *
 6  2001:2034:a:b9::1  29.491 ms  29.463 ms  29.544 ms
 7  2001:2035:0:5c0::2  29.596 ms  29.547 ms  29.894 ms
 8  2604:cac0:a104:d::2  29.415 ms  28.672 ms  145.388 ms

And forcing TCP (vice UDP) ... fails to complete:

$ tracert6 -S aur.archlinux.org
traceroute to aur.archlinux.org (2604:cac0:a104:d::2) from 2a02:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx, port 33434, from port 4035, 30 hops max, 60 bytes packets
 1  _gateway (2a02:xxxx:xxxx::x)  0.431 ms  0.395 ms  0.437 ms
 2  lo0-0.bng4.wh-man.zen.net.uk (2a02:8010::156)  28.676 ms  29.933 ms  23.803 ms
 3  * * *
 4  * * *
 5  * * *
 6  ldn-b2-link.ip.twelve99.net (2001:2034:a:3ab::1)  28.461 ms  27.782 ms  27.983 ms
 7  haproxy-ic-335732.ip.twelve99-cust.net (2001:2035:0:5c0::2)  27.806 ms  28.038 ms  28.491 ms
 8  * * *
 9  * * *
10  * * *
11  * * *
12  * * *
13  * * *
14  * * *
15  * * *
16  * * *
17  * * *
18  * * *
19  * * *
20  * * *
21  * * *
22  * * *
23  * * *
24  * * *
25  * * *
26  * * *
27  * * *
28  * * *
29  * * *
30  * * *

On a box constrained to IPv4, `openssl s_client` is instant.

$ openssl s_client -connect aur.archlinux.org:443 -servername aur.archlinux.org </dev/null
Connecting to 209.126.35.78
CONNECTED(00000003)
...
Verify return code: 0 (ok)
---
DONE

On a dual stack box (prefer IPv6), `openssl s_client` rarely completes.

$ openssl s_client -connect aur.archlinux.org:443 -servername aur.archlinux.org </dev/null
Connecting to 2604:cac0:a104:d::2
CONNECTED(00000003)

Hangs after `CONNECTED`, until interrupted. With `curl` IPv6 usually times out (likewise with AUR helpers like `yay`).

Doesn't seem like a local problem, or even a blacklist problem as default `tracert6` works.

I would very much prefer not to have to make local `/etc/hosts`entries for *archlinux.org IPv4 addresses to connect to Arch properties.

ewaller · 2026-10-18 17:29:47

stronnag wrote:

For some time now, I'm unable to connect reliably to any archlinux.org property over IPv6. IPv4 works perfectly, IPv6 works everywhere else (apart from *archlinux.org, where it fails probably 90% of the time).

It looks like you were okay with IPv6 until about May of this year.

maksverver, It looks like you are trying to connect via IPv6 as well whereas the Tor address is IPv4.

Can you both tell me if you are or are not receiving a message from the forums that you are banned? Neither of you are apparently banned, but there is the possibility of an address being banned -- but if it is it does not happen silently, the forums will display a page indicating there is a ban in place.

stronnag · 2026-10-18 17:44:46

ewaller wrote:

stronnag wrote:
For some time now, I'm unable to connect reliably to any archlinux.org property over IPv6. IPv4 works perfectly, IPv6 works everywhere else (apart from *archlinux.org, where it fails probably 90% of the time).
It looks like you were okay with IPv6 until about May of this year.
maksverver, It looks like you are trying to connect via IPv6 as well whereas the Tor address is IPv4.
Can you both tell me if you are or are not receiving a message from the forums that you are banned? Neither of you are apparently banned, but there is the possibility of an address being banned -- but if it is it does not happen silently, the forums will display a page indicating there is a ban in place.

May would appear reasonable. Don't appear to be banned; certainly have not been notified. As noted, IPv4 works all the time; IPv6 fails most of the time. I refuse to believe that Arch is sufficiently wicked to ban users based solely on IPv4/IPv6 . In my case, you would have to ban my v6 /64 while allowing my v4 /29. Somehow I doubt this degree of intrigue.

Based on `tracert6` it seems that the intermediate `twelve99.net` is more than capable of confusing IPv6 routing. From `traceroute6 -T` on my FreeBSD box (just to add another "not local Arch" point).

...
6  ldn-b2-link.ip.twelve99.net (2001:2034:a:b9::1)  30.573 ms  28.591 ms
    ldn-b2-link.ip.twelve99.net (2001:2034:a:3ab::1)  31.584 ms
 7  haproxy-ic-360670.ip.twelve99-cust.net (2001:2035:0:1983::2)  29.975 ms
    haproxy-ic-335732.ip.twelve99-cust.net (2001:2035:0:5c0::2)  29.154 ms
    haproxy-ic-360670.ip.twelve99-cust.net (2001:2035:0:1983::2)  30.403 ms
 8  * * *
 9  * * *
10  * * *
11  * * *
12  * * *
13  * * *
14  * * *
15  * * *
16  * * *
17  * * *
18  * * *
19  * * *
20  * * *
21  * * *
22  * * *
23  * * *
24  * * *
25  * * *
26  * * *
27  * * *
28  * * *
29  * * *
30  * * *

stronnag · 2026-10-18 17:54:12

I also very much doubt this directly an Arch Linux admin issue. Rather it belongs to Arch's ISP or close upstream.

Last edited by stronnag (2026-10-18 17:54:27)

seth · 2026-10-18 19:41:47

Since it hangs/fails at the haproxy it's very likely to be the DDOS mitigation (which will simply discriminate IPv4 and IPv6 behavior, resp. the IPv4 was whitelisted or the IPv6 flared up before)

Did you trace the IPv4 though? haproxy can block TRACE and I'm not getting a trace answer from there at all (on IPv4 and the connection was never a problem)

maksverver · 2026-10-18 19:52:16

stronnag wrote:

For some time now, I'm unable to connect reliably to any archlinux.org property over IPv6. IPv4 works perfectly, IPv6 works everywhere else (apart from *archlinux.org, where it fails probably 90% of the time).

From my side, both IPv4 and IPv6 fail intermittently. You are right that it IPv4 appears to be more reliable than IPv6, but it's more like a 10% vs a 90% failure rate, and not that the issue affects only one of the two protocols.

stronnag wrote:

I also very much doubt this directly an Arch Linux admin issue. Rather it belongs to Arch's ISP or close upstream.

Maybe; do you know of any nearby hosts to test with?

From my side, all archlinux.org subdomains are affected; without any additional data points I wouldn't assume the issue is more widespread than that.

ewaller wrote:

Can you both tell me if you are or are not receiving a message from the forums that you are banned?

No, nothing from the forums (and I'm barely active here anyway), but I did get unsubscribed from the aur-general mailing list (note: not arch-general) on October 1 "because it has received a number of bounces". I doubt it's related though, since my home IP is in no way involved in email delivery.

stronnag · 2026-10-18 20:30:18

seth wrote:

Since it hangs/fails at the haproxy it's very likely to be the DDOS mitigation (which will simply discriminate IPv4 and IPv6 behavior, resp. the IPv4 was whitelisted or the IPv6 flared up before)
Did you trace the IPv4 though? haproxy can block TRACE and I'm not getting a trace answer from there at all (on IPv4 and the connection was never a problem)

Indeed, it block IPv4 trace as well. Only ICMP works on both v4/v6. So the haproxy is probably innocent. Very annoying.

seth · 2026-10-18 20:38:00

2604:cac0:a104:d::2 is aur.archlinux.org, though.
So this seems to fall apart at the SSL level
Do you get 301 from

curl -6v http://aur.archlinux.org >/dev/null

?

And because of my experiences w/ bugs.kde.org: can you maybe actually

curl -6vL http://aur.archlinux.org

Arch Linux

#101 2026-06-02 13:35:50

Re: AUR connection issues (EOF/TLS errors)

#102 2026-06-02 13:51:14

Re: AUR connection issues (EOF/TLS errors)

#103 2026-06-02 14:21:59

Re: AUR connection issues (EOF/TLS errors)

#104 2026-08-18 18:19:48

Re: AUR connection issues (EOF/TLS errors)

#105 2026-08-18 19:54:45

Re: AUR connection issues (EOF/TLS errors)

#106 2026-08-18 20:06:21

Re: AUR connection issues (EOF/TLS errors)

#107 2026-10-04 23:54:55

Re: AUR connection issues (EOF/TLS errors)

#108 2026-10-05 04:31:55

Re: AUR connection issues (EOF/TLS errors)

#109 2026-10-05 06:49:58

Re: AUR connection issues (EOF/TLS errors)

#110 2026-10-05 11:05:06

Re: AUR connection issues (EOF/TLS errors)

#111 2026-10-05 12:07:46

Re: AUR connection issues (EOF/TLS errors)

#112 2026-10-09 20:34:40

Re: AUR connection issues (EOF/TLS errors)

#113 2026-10-10 19:43:55

Re: AUR connection issues (EOF/TLS errors)

#114 2026-10-13 22:27:12

Re: AUR connection issues (EOF/TLS errors)

#115 2026-10-18 02:32:37

Re: AUR connection issues (EOF/TLS errors)

#116 2026-10-18 07:01:00

Re: AUR connection issues (EOF/TLS errors)

#117 2026-10-18 15:39:42

Re: AUR connection issues (EOF/TLS errors)

#118 2026-10-18 17:00:57

Re: AUR connection issues (EOF/TLS errors)

#119 2026-10-18 17:29:47

Re: AUR connection issues (EOF/TLS errors)

#120 2026-10-18 17:44:46

Re: AUR connection issues (EOF/TLS errors)

#121 2026-10-18 17:54:12

Re: AUR connection issues (EOF/TLS errors)

#122 2026-10-18 19:41:47

Re: AUR connection issues (EOF/TLS errors)

#123 2026-10-18 19:52:16

Re: AUR connection issues (EOF/TLS errors)

#124 2026-10-18 20:30:18

Re: AUR connection issues (EOF/TLS errors)

#125 2026-10-18 20:38:00

Re: AUR connection issues (EOF/TLS errors)

Board footer