a month ago
Hi,
My API service was returning 502 errors at some point today. After restarting and redeploying, the service is fully healthy — no errors in logs, starts correctly.
However, requests from the browser still receive 502 Bad Gateway, which causes CORS errors on the client side (no headers are returned on a 502).
When I test directly via curl, the API responds correctly. This makes me think a CDN or proxy layer in front of my service is caching the old 502 response.
Is there a cached error response that needs to be purged for my service?
Domain: api.fallen.app
Thanks
Pinned Solution
a month ago
Have you tried removing the domain from Railway then re-adding it after ~10-15 mins?
10 Replies
a month ago
Our proxy does not cache responses, so there is no cached 502 that needs purging. Your domain api.fallen.app shows DNS fully propagated, certificate valid, and verification complete. Since curl returns correct responses, the 502 in the browser is likely caused by browser-level DNS or HTTP caching, or a service worker in your client app - try clearing browser cache, testing in incognito, or flushing your local DNS resolver.
Status changed to Awaiting User Response Railway • 29 days ago
a month ago
Following the incident earlier today, our users are still experiencing intermittent 502 errors even though the service is back up. It seems the 502 responses are cached at the browser/DNS level for some users and are resolving slowly.
Is there anything you can do on your end to help flush residual errors faster?
Thanks
Status changed to Awaiting Railway Response Railway • 29 days 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 • 29 days ago
a month ago
I ran nslookup and I couldn't find a TXT record. Make sure you've added the verification TXT record correctly. It should be added to _railway-verify.api.fallen.app.
a month ago
Hi, the domain is already verified and fully working - preflight requests return correct CORS headers. The actual issue was intermittent 502 errors visible directly in the Railway HTTP logs, returning randomly alongside 204 responses. This started during your incident earlier today but has since resolved on its own. Nothing has changed on our side since we started using Railway nearly 2 years ago - this issue appeared out of nowhere yesterday. Our users were unable to access the application for at least 2 hours, which is not acceptable. I would like to understand what caused it ?
a month ago
I'm not exactly sure what would've caused the sudden rise of 502. The recent incident would have not affected networking, as it primarily affected builds on Metal.
Additionally, as I mentioned above, I would highly recommend adding the TXT record to your domain. I have ran nslookup again and it returned NXDOMAIN on your TXT records.
Keep in mind that when the certificates expire for the domain (which will cause your domain to return 4xx), they will not be automatically issued unless the TXT records are present.
a month ago
Hi, when I set up the domain on Railway, only the CNAME record was provided. I don't see any TXT record value in the interface. Could you tell me where to find it ?
a month ago
Just bumping this, I need an answer quickly. Thanks.
a month ago
Have you tried removing the domain from Railway then re-adding it after ~10-15 mins?
a month ago
I removed the domains and re-added them, it's OK, now I have the TXT field. Perhaps it would be helpful to communicate about this kind of changes in the future; I don't think I've seen any email or anything regarding this requirement, I would never have known...
Thanks anyway.
a month ago
The TXT requirement was relatively recent. It’s possible that you have added your domain before then, and the certificate expired after the requirement was added.
Status changed to Solved 0x5b62656e5d • 26 days ago