4 days ago
Starting around June 4, 2026 (~3 days ago), our Android app began
intermittently failing on POST requests with "Network request failed" /
connection resets. No deploy or code change on our side coincided with the
onset.
It is specific to Android (OkHttp over HTTP/2). Against the SAME service URL:
-
Android (OkHttp, HTTP/2): intermittent failures on POSTs — even on fresh,
non-idle connections; rapid/concurrent sends (e.g. chat) made it noticeably worse -
iOS (NSURLSession, HTTP/2): never fails
-
curl (HTTP/1.1): fine
-
Node http2 client: 30 concurrent POSTs over ONE h2 session =
0 failures, no GOAWAY
So your edge handles HTTP/2 fine for iOS, curl and Node — this looks specific
to OkHttp <-> your edge over HTTP/2.
Note: this is DISTINCT from the documented 60s edge keep-alive (idle-reuse).
These failures happen even on fresh, non-idle connections.
Workaround that resolved it in our testing: forcing OkHttp to HTTP/1.1
(OkHttpClient.Builder().protocols(listOf(Protocol.HTTP_1_1))). After that,
the failures stopped.
Questions:
-
Did anything change on Railway's HTTP edge / HTTP/2 handling recently
(around June 4, 2026)?
-
Is this a known OkHttp <-> edge interop issue over HTTP/2?
-
Is a fix expected? We'd prefer to re-enable HTTP/2 on Android once it's
safe, rather than stay pinned to HTTP/1.1.
Setup: Node 22 / NestJS, Docker image, single replica.
3 Replies
4 days ago
Our edge proxy has a keep-alive timeout of 60 seconds, as documented in Specs & Limits, which matches your reproduction. This value is not user-configurable.
Status changed to Awaiting User Response Railway • 4 days ago
Railway
Our edge proxy has a keep-alive timeout of 60 seconds, as documented in [Specs & Limits](https://docs.railway.com/networking/public-networking/specs-and-limits), which matches your reproduction. This value is not user-configurable.
4 days ago
Thanks — the 60s edge keep-alive explains the idle-reuse case.
One more data point, in case it's a known interop issue: the failures are
specific to Android (OkHttp). Against the SAME edge:
-
iOS (NSURLSession): never fails
-
curl (HTTP/1.1): fine (only the documented 60s idle-reuse, as expected)
-
Node http2 client: 30 concurrent POSTs on one h2 session = 0 failures, no GOAWAY
-
Android (OkHttp, HTTP/2): intermittent ECONNRESET / "Network request failed"
on POSTs — even on fresh, non-idle connections
So the edge clearly handles HTTP/2 fine for other clients — this looks like an
OkHttp <-> edge interop issue, not the 60s timeout. We've worked around it
client-side (forcing fresh connections per POST), so we're unblocked.
Is this a known issue with OkHttp / Android clients on Railway's edge? Any
recommended client settings (protocol/keep-alive) you'd suggest for OkHttp?
Status changed to Awaiting Railway Response Railway • 4 days ago
4 days ago
This thread has been opened as a bounty so the community can help solve it.
Status changed to Open Railway • 4 days ago
4 days ago
.