a month 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
a month 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 • about 1 month ago
Status changed to Awaiting Railway Response Railway • about 1 month ago
a month 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 • about 1 month ago
a month 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 • about 1 month 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-limits](http://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 :)
a month 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.
a month 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?
a month ago
I'm going to defer this back to the community. I had just popped in to correct some information. Sorry for the intrusion.
a month ago
@wonyus what http server/framework are you using in your backend?
domehane
@**wonyus** what http server/framework are you using in your backend?
a month 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 • about 1 month ago