14 days ago
The DNS record shows a warning even though it seems correctly configured and proxied at cloudflare. Besides this warning, strangely, some endpoints returns a 404 from railway when called and it does not "activate" the serverlesse service. One endpoint that returns a JSON, when called, activates the serverless and then, the other service that was previously returning a 404, now returns correctly.
Calling the CNAME content directly, returns the 404 always.
How to make sure the dns is correctly setup ? I have both the CNAME apiand the TXT _railway-verify.api set.
Why does some endpoints activate the serverless while others don't ?
Attachments
16 Replies
13 days ago
We're sorry for the trouble. We're aware of an issue affecting DNS resolution and are working on it. Follow updates at https://status.railway.com/incident/cmlv7yk1o0169a8bl7vvvqwir
Status changed to Awaiting User Response Railway • 13 days ago
13 days ago
Sorry - on closer review the DNS warning you're seeing is expected when using Cloudflare with proxy enabled (orange cloud). Cloudflare masks the underlying CNAME target behind their own IPs, so Railway can't verify the record directly. As long as your CNAME is pointed at the correct target, traffic will route properly.
A couple things to check:
Cloudflare SSL/TLS mode: Make sure this is set to Full (not "Flexible" and not "Full (Strict)"). Flexible will cause redirect loops or connection errors, and Full Strict can fail because Railway's edge certificate won't match Cloudflare's strict validation.
Calling the CNAME target directly: Hitting 0s9xqbvo.up.railway.app in your browser will always return a 404. That hostname is only a routing target for your CNAME, not a service domain you can browse to directly. Your requests should go through your custom domain api.vivenda.io).
Some endpoints not waking serverless: When your service is asleep, the first request wakes it up. During the cold start, your Express app may not be ready to handle all routes immediately. If certain routes (like a health check or a simple JSON endpoint) initialize faster than others, those will respond first while other routes may 404 until the app is fully started. Once the service is awake, all routes should work normally.
If the issue persists after checking the SSL mode, let us know and we can dig deeper.
Status changed to Solved sam-a • 13 days ago
sam-a
Sorry - on closer review the DNS warning you're seeing is expected when using Cloudflare with proxy enabled (orange cloud). Cloudflare masks the underlying CNAME target behind their own IPs, so Railway can't verify the record directly. As long as your CNAME is pointed at the correct target, traffic will route properly.A couple things to check:Cloudflare SSL/TLS mode: Make sure this is set to Full (not "Flexible" and not "Full (Strict)"). Flexible will cause redirect loops or connection errors, and Full Strict can fail because Railway's edge certificate won't match Cloudflare's strict validation.Calling the CNAME target directly: Hitting 0s9xqbvo.up.railway.app in your browser will always return a 404. That hostname is only a routing target for your CNAME, not a service domain you can browse to directly. Your requests should go through your custom domain api.vivenda.io).Some endpoints not waking serverless: When your service is asleep, the first request wakes it up. During the cold start, your Express app may not be ready to handle all routes immediately. If certain routes (like a health check or a simple JSON endpoint) initialize faster than others, those will respond first while other routes may 404 until the app is fully started. Once the service is awake, all routes should work normally.If the issue persists after checking the SSL mode, let us know and we can dig deeper.
13 days ago
I'm still receiving the 404 on all of them. Can you check based on the request id ? Here it goes: thKfxnKiS0mb_eZPwoOzXw
Now, after just redeploying the service, everything works as expected
Status changed to Awaiting Railway Response Railway • 13 days ago
Status changed to Awaiting User Response Railway • 13 days ago
13 days ago
both custom domains: api.novavivenda.io/status and api.novavivenda.com.br/status were returing 404. Here's a request id for the other domain 3C6R50TPSLKueN1CozsQ6Q
Status changed to Awaiting Railway Response Railway • 13 days ago
13 days ago
The request ID doesn't help here. Please provide the domains that are returning 404 errors.
Doesn't exist - https://www.nslookup.io/domains/api.novavivenda.io/dns-records/
Loads fine - https://api.novavivenda.com.br/
Status changed to Awaiting User Response Railway • 13 days ago
13 days ago
Unfortunately the error cant be reproduced anymore. I'll create an cron checker and once it fails, I'll come back here. The other domain is api.novavivenda.com.br . Thanks for the quick responses
Status changed to Awaiting Railway Response Railway • 13 days ago
13 days ago
One more question: Do you know why the warning icon regarded the proxied CNAME ? Doe it always show as warning when proxied ?
Status changed to Awaiting User Response Railway • 13 days ago
13 days ago
only the vivenda.io which is managed by cloudflare. Cloudflare SSL/TLS mode was set to Full
Status changed to Awaiting Railway Response Railway • 13 days ago
Status changed to Awaiting User Response Railway • 12 days ago
12 days ago
Is there any missing configuration ?
I got a 404 again at 2026-02-22T04:52:34.278Z
this is the text response {"status":"error","code":404,"message":"Application not found","request_id":"7otV3JAVRmeA_Pflss7a6g"}
Attachments
Status changed to Awaiting Railway Response Railway • 12 days ago
12 days ago
Gotcha, we'll be looking into that. We will follow up when we have more information.
Status changed to Awaiting User Response Railway • 12 days ago
11 days ago
Its returning 404 right now. Can you check ?
Status changed to Awaiting Railway Response Railway • 11 days ago
11 days ago
We will be looking into that. We will follow up when we have more information.
Status changed to Awaiting User Response Railway • 11 days ago
11 days ago
An update: we have resolved the underlying issue that was causing the 404s. You should not see this going forward after a redeploy.
4 days ago
This thread has been marked as solved automatically due to a lack of recent activity. Please re-open this thread or create a new one if you require further assistance. Thank you!
Status changed to Solved Railway • 4 days ago
