24 days ago
why i got 502 from railway when gql req over http and take time over 1 minute
{
"requestId": "STZ_s6hEQ5KZyJGNmrpb1w",
"timestamp": "2026-04-16T15:53:56.102313617Z",
"method": "POST",
"path": "/api/v1/graphql/query",
"host": "mobile-api-dev.tradinglens.app",
"httpStatus": 502,
"upstreamProto": "",
"downstreamProto": "HTTP/1.1",
"responseDetails": "",
"totalDuration": 79220,
"upstreamAddress": "",
"clientUa": "Dart/3.9 (dart:io)",
"upstreamRqDuration": 79220,
"txBytes": 109,
"rxBytes": 1873,
"srcIp": "110.169.129.234",
"edgeRegion": "asia-southeast1-eqsg3a",
"upstreamErrors": "[{\"deploymentInstanceID\":\"be940f26-f54e-466d-aeed-d721ed5080ef\",\"error\":\"connection closed unexpectedly\",\"duration\":79220}]"
}
7 Replies
24 days ago
The HTTP logs show your request ran for ~79 seconds and your application closed the connection without sending a response ("connection closed unexpectedly"), which is why our proxy returned a 502. This is not a platform timeout - our proxy was waiting on your application the entire time. Your application or its upstream dependencies (e.g., database) likely hit an internal timeout or crashed while processing that long-running GraphQL query.
Status changed to Awaiting User Response Railway • 24 days ago
Status changed to Awaiting Railway Response Railway • 24 days ago
24 days ago
This thread has been marked as public for community involvement, as it does not contain any sensitive or personal information. Any further activity in this thread will be visible to everyone.
Status changed to Open Railway • 24 days ago
24 days ago
Hello wonyus,
your request took 79s and railway's proxy keep-alive timeout is 60s, that's what's killing it. documented here: docs.railway.com/networking/public-networking/specs-and-limits
to fix this use websockets for long running graphql requests instead of http, railway supports it and it won't hit that limit
Hope this help you :)
Status changed to Open brody • 24 days ago
domehane
Hello wonyus,your request took 79s and railway's proxy keep-alive timeout is 60s, that's what's killing it. documented here: docs.railway.com/networking/public-networking/specs-and-limitsto fix this use websockets for long running graphql requests instead of http, railway supports it and it won't hit that limitHope this help you :)
24 days ago
The keep-alive time has nothing to do with how long a request can stay open. Currently, it's 5 minutes for uploads and 15 minutes for downloads.
brody
The keep-alive time has nothing to do with how long a request can stay open. Currently, it's 5 minutes for uploads and 15 minutes for downloads.
24 days ago
Could this be related to:
Response size limits?
Buffering / streaming behavior (GraphQL upload handling)?
Reverse proxy timeout before response is fully sent?
Is there a way to confirm whether Railway is terminating the response before it’s fully flushed back to the client?
24 days ago
I'm going to defer this back to the community. I had just popped in to correct some information. Sorry for the intrusion.
24 days ago
@wonyus what http server/framework are you using in your backend?
domehane
@wonyus what http server/framework are you using in your backend?
24 days ago
i use go with net/http, but now i just have to resolve this problem.
solution:
- fix http idle timeout on backend with no idle timeout.
Status changed to Solved wonyus • 24 days ago