Intermittent TLS “connection reset by peer”

MusicBrainz Development
1

Hello, I’m new to the forum but I’ve been using the MusicBrainz API in iOS 26 for a few weeks without any issue. But after the power outage that the Internet Archive had last week I’ve had Intermittent TLS “connection reset by peer” errors. I’ve also been testing this in the Terminal on macOS using curl (I’ve been using this: curl -vIL https://coverartarchive.org/release/fef8b229-ee77-4e63-a07f-222c1ad56c97).
Sometimes the request works and I get the expected 307 redirect and then the JSON from archive.org; other times the TLS connection to coverartarchive.org is reset immediately after the ClientHello. Here is an example of what it returns (I tried forcing IPv4 to confirm it wasn’t an IPv6 issue):
curl -4 -vIL https://coverartarchive.org/release/fef8b229-ee77-4e63-a07f-222c1ad56c97

  • Host coverartarchive.org:443 was resolved.
  • IPv6: (none)
  • IPv4: 142.132.240.1
  • Trying 142.132.240.1:443…
  • Connected to coverartarchive.org (142.132.240.1) port 443
  • ALPN: curl offers h2,http/1.1
  • (304) (OUT), TLS handshake, Client hello (1):
  • CAfile: /etc/ssl/cert.pem
  • CApath: none
  • Recv failure: Connection reset by peer
  • LibreSSL/3.3.6: error:02FFF036:system library:func(4095):Connection reset by peer
  • Closing connection
    curl: (35) Recv failure: Connection reset by peer

Is this happening with anyone else? Am I possibly doing something wrong on my end, or is there something that happened during the power outage at the Internet Archive that could possibly be causing this?

If there is anything else I can add to help troubleshoot this please let me know!

1 Like
2

I have definitely seen those several times the last days when using Picard. So it’s not only you, I’m sure this is somewhere on the Internet Archive side.

3

Thank you for confirming, I really appreciate it!

Is this something I should try and now make Internet Archive aware of separately you think? Maybe they don’t even know if no one has reported to them… I’ll look into this as well

4

I’m aware of this issue, but I didn’t had time to investigate yet.

MeB admins will have a look very soon. Thanks for the report.

8 Likes
5

this has been driving me crazy, thought something was wrong on my end! happy to see someone else encountering this too. thanks for looking into it!

2 Likes
6

I’m encountering an identical intermittent issue with ListenBrainz. Given the timing and identical IP, I suspect it’s affecting many services and may not be the fault of the Internet Archive. It affects non-API domains, but I’ve never had an issue on my browser, perhaps because it retries and/or keeps the session open.

$ curl -4 -vIL "https://listenbrainz.org" "https://api.listenbrainz.org"

Output 
*   Trying 142.132.240.1:443...
* Connected to listenbrainz.org (142.132.240.1) port 443
* ALPN: curl offers h2,http/1.1
* (304) (OUT), TLS handshake, Client hello (1):
*  CAfile: /etc/ssl/cert.pem
*  CApath: none
* Recv failure: Connection reset by peer
* LibreSSL/3.3.6: error:02FFF036:system library:func(4095):Connection reset by peer
* Closing connection
curl: (35) Recv failure: Connection reset by peer
*   Trying 142.132.240.1:443...
* Connected to api.listenbrainz.org (142.132.240.1) port 443
* ALPN: curl offers h2,http/1.1
* (304) (OUT), TLS handshake, Client hello (1):
*  CAfile: /etc/ssl/cert.pem
*  CApath: none
* Recv failure: Connection reset by peer
* LibreSSL/3.3.6: error:02FFF036:system library:func(4095):Connection reset by peer
* Closing connection
curl: (35) Recv failure: Connection reset by peer

Several downstream applications which neglect to retry requests on failure have encountered issues:

List of GitHub issues
7

I take back the above: even trying with a single album I’m getting the issue each and every time now.

8

Seeing this issue as well. Definitely intermittent, but seems to generate on imports that take longer.

9

I’m hitting this issue on almost every other request. It makes musicbrainz pretty much unuseable for imports.

10

I made a change, do you still see the same number of issues?

How do you test?

1 Like
11

I don’t think it happened to me but @chaban collection could never load completely before I made a “retry on error” fix in COLLECTION HIGHLIGHTER.

It was happening to chaban with old version 2024.11.28 on his 25,000+ (!) release collection.

12

I’m also haunted by this, and it looks like it’s happening when the URL resolves to moon.musicbrainz.org instead of one of the archive.org servers (like dn710602.ca.archive.org )

This is curl’s output on latest macOS 26.2

curl -vIL https://coverartarchive.org/release/35dc519b-8443-451a-84c4-021d5b6b874a/front-250
* Host coverartarchive.org:443 was resolved.
* IPv6: 2a01:4f8:c01e:70::1
* IPv4: 142.132.240.1
*   Trying [2a01:4f8:c01e:70::1]:443...
* Connected to coverartarchive.org (2a01:4f8:c01e:70::1) port 443
* ALPN: curl offers h2,http/1.1
* (304) (OUT), TLS handshake, Client hello (1):
*  CAfile: /etc/ssl/cert.pem
*  CApath: none
* Recv failure: Connection reset by peer
* LibreSSL/3.3.6: error:02FFF036:system library:func(4095):Connection reset by peer
* Closing connection
curl: (35) Recv failure: Connection reset by peer
13

Happening for me simply using the https://musicbrainz.org/ws/2/artist/{*mbid*} api to get artist info. I’m throttling my script well below 50/rpm and seeing maybe 1 in 10 succeed. The other are returning “Connection reset by peer“ (using the Python requests client)

Update: It seems to be doing much better at a different time of day.

Results:

  • Wednesday evening USA Mountain Standard Time: Frequent peer resets :slightly_frowning_face:
  • Thursday morning MST: 100% success :grinning_face:

Indicates a problem with overall load on the system during peak times.

14

Just to add I’ve also seen multiple discussions online where people report similar connectivity issues related to Hetzner, especially with some German locations. Quite often the suggested workaround is migrating workloads from Germany to Finland or putting Cloudflare in front to stabilize routing and availability.

1 Like
15

Hi, I’m experiencing a very similar issue. I’m using the MusicBrainz API from a Node.js script and after several requests the connection starts getting reset. At the same time I can see packet loss to static.227.51.201.195.clients.your-server.de increasing up to ~95%.

After the first connection reset, the API becomes unreachable for several minutes not only from my ISP, but also from my Hetzner server which did not send any requests at that moment. Interestingly, it is still reachable from another server I have in a different AS.

Because of this behaviour, I suspect this might be related to routing problems towards Hetzner rather than strict API rate limiting. I’ve previously observed similar routing instability on my own Hetzner-hosted services without Cloudflare in front, connectivity to Hetzner can become very unreliable from some networks.

1 Like
16

Hi,
I’m also observing (and seeing other users hit) this issue when trying to use ListenBrainz APIs. In my case, I’m seeing anywhere from 8 to 82 listens (now playing or submission) fail a day, as well as /user/<user>/playlists/createdfor or individual playlist fetches hitting the same problem.

So far, I haven’t seen any 429 errors in the log signifying a rate limit was hit.
Is there any possible mitigation client-side (aside from retries?)