13 days ago
Summary
We're seeing intermittent request failures where our backend receives the request and returns 200, but the client never receives the response and reports a connection failure
(net::ERR_FAILED / "Network Error"). It appears to be the Railway edge resetting the client-facing leg of reused keep-alive connections.
What we observe
- Client is a React Native Android app using OkHttp (User-Agent: okhttp/4.12.0), HTTPS.
- The failing request reaches our backend — we have the forwarded request (with x-railway-edge: ams1, x-railway-request-id, x-forwarded-for) and the backend responds 200.
- Despite the 200, the client gets net::ERR_FAILED and never receives the response body.
- Clear pattern by connection state, not endpoint or method:
- The first request on a fresh connection succeeds (e.g. a sign-in POST).
- A subsequent request that reuses the keep-alive connection (a body-carrying POST shortly after) fails.
- Plain GETs and fresh-connection requests are unaffected.
- It's not client-network-specific — it reproduces for multiple end users on different networks (mobile data and WiFi), so it's on the shared path through your edge.
What we've ruled out
- Backend errors — it returns 200; the failure is purely on the edge→client response leg.
- Client network / IPv6 — multiple users, multiple networks.
- We confirmed the connection-reuse trigger: disabling HTTP keep-alive on the client (one fresh TCP+TLS connection per request) eliminates the failures entirely. That strongly
implicates how the edge handles reused connections.
1 Replies
13 days ago
Our edge closes idle HTTP/1.1 connections after 60 seconds of inactivity between requests (documented in Specs & Limits). The pattern you describe, where the second request on a reused connection fails while the first succeeds, is consistent with a race between OkHttp's connection pool attempting to reuse a connection and the edge tearing it down at the idle boundary. Configuring OkHttp's connection pool keep-alive duration below 60 seconds (e.g. 30s) or enabling retry-on-connection-failure should prevent these from surfacing as client errors.
Status changed to Awaiting User Response Railway • 13 days ago
6 days ago
This thread has been marked as solved automatically due to a lack of recent activity. Please re-open this thread or create a new one if you require further assistance. Thank you!
Status changed to Solved Railway • 6 days ago