23 days 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
21 days ago
Have you tried removing the domain from Railway then re-adding it after ~10-15 mins?
10 Replies
23 days 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 • 23 days ago
23 days 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 • 23 days ago
23 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 • 23 days ago
23 days 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.
23 days 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 ?
23 days 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.
22 days 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 ?
21 days ago
Just bumping this, I need an answer quickly. Thanks.
21 days ago
Have you tried removing the domain from Railway then re-adding it after ~10-15 mins?
20 days 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.
20 days 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 • 20 days ago