I’ve been getting these errors as well in SIN and NRT the past 48 hours. Very intermittent and hard to trace. My PU02 log follows up with a SIGKILL, possibly due to a worker timing out from the connection failure. It is not a memory issue as suggested.
12:54:34 [PU02] could not complete HTTP request to instance: legacy hyper error: client error (SendRequest) (source: connection closed before message completed)
12:54:34 [2026-04-20 12:54:34 +0000] [657] [ERROR] Worker (pid:944) was sent SIGKILL! Perhaps out of memory?
Anyone else still getting these and have any leads on how to resolve?
Please start a new thread. All of these errors are very generic connection errors and can be due to a number of different reasons ranging from app issues to network issues. Please do not reuse the same thread.
Hi @somt0xhi, @PeterCxy, following up on my questions, currently my database is located in the FRA region, so using machines in distant regions could affect my app’s performance. Is there any alternative?
Also, what’s the cause behind the issues routing from APAC region to EU? Is this particularly a fly proxy issue, or can it still be related to my app?
The internet and the fact that there are only a limited amount of international bandwidth available between APAC and EU, and we currently do not have higher QoS than other traffic over Tier-1 providers, unfortunately.
The reason why these errors tend to be more visible on Fly is because we accept traffic locally near the user via Anycast and then forward those traffic to where your app is running. This means that any internet issue between these faraway regions also get surfaced as fly-proxy errors, while if there were no Anycast (traffic going straight from users to the target region), there would be no errors shown to you but the users would still likely see connectivity issues intermittently.
We actually do support non-Anycast mode too: if you provide a region when you assign a new public IP to your app, that IP will be for that region only and never advertised outside of there. Requests over that IP will not result in errors visible to you even if the Internet decides to be unhappy, but, like stated above, it does not mean errors / slowness / … are not seen by your users connecting from these faraway regions.
The usual recommendation here would be to cache and serve what you can serve locally within the region and not perform a full database roundtrip every time. This could mean some logic in your app to do that caching or a read-only database follower in different regions. But if you need strong consistency for some reads, then unfortunately you will still need to forward those requests to the main database instance.