When you set dev.example.com to Proxied (orange cloud), Cloudflare sits in front of Railway. Railway can’t directly see the CNAME anymore, so it shows the yellow warning. When you switch to DNS only (grey cloud), Railway can see the real record and it turns green.

Your Cloudflare plan isn’t the issue. Free plan works fine.

For development, there’s usually no real benefit to keeping it proxied. It just adds another layer that can cause confusion. I’d leave dev.example.com as DNS only unless you specifically need Cloudflare features for it.

About the 502, yes, proxying can cause that. If Cloudflare can’t properly reach your Railway service (SSL mismatch, temporary restart, or origin not responding), it will return 502. That would explain why it worked earlier and later showed 502 without you changing anything.

in short, If you switch dev to DNS only and the 502 disappears, then Cloudflare proxy was the cause.

"For development, there’s usually no real benefit to keeping it proxied."

That's what I thought as well.

But here's what I don't understand: why is it that example.com proxied doesn't show the warning and dev.example.com does?
I asked Claude about this and it said that example.com could be an A record and dev.example.com was a CNAME, but that's not true. They are both set to CNAME.

Am I running into potential issues in the future by having example.com set to proxied? Or is there any correlation between dev.example and the 502 issue when set to proxied, but example.com set to proxied is not prone to that error for the same reason?

Since I changed dev to DNS only, it has been working. I haven't merged my dev repo into main yet, so I can't confirm that example.com has the 502 issue or not. I will only merge when this first version is complete, so I can't test it just yet.

Here's what Claude just said when I asked it again:
The difference likely comes down to CNAME flattening.

Cloudflare automatically flattens CNAMEs at the zone apex (example.com) because DNS spec doesn't allow CNAME records at the root. So even though you set it as CNAME in Cloudflare's UI, it gets served as an A record to the outside world. Railway probably detects an A record pointing correctly and doesn't flag it.

For dev.example.com (a subdomain), no flattening happens — it stays a true CNAME. When proxied, Railway sees Cloudflare's IPs instead of its own infrastructure, and that's what triggers the warning. Railway likely checks whether the domain resolves to their expected endpoints during validation.

On your 502 risk with example.com proxied: Yes, you likely have the same underlying issue, it's just hidden because Railway's validator sees an A record (post-flattening) rather than a CNAME pointing somewhere unexpected. The actual traffic behavior at runtime could still produce 502s for the same reason — Cloudflare proxying can interfere with Railway's routing/TLS termination regardless of what record type Railway detected during setup.

The fact that dev.example.com with DNS only fixed your 502s is a strong signal. When you're ready to test production, I'd set example.com to DNS only as well before merging, unless you specifically need Cloudflare proxy features (DDoS protection, caching, etc.). Railway handles TLS on its own, so you lose less than you'd think by going DNS only.

---

So now I wonder: should I always just use DNS Only even for example.com?

Railway is able to work with proxied Cloudflare without any problems, and it's even recommended by Railway to keep it on. The only possibility I can think of is that you might have done the setup incorrectly. For reference, we're using a subdomain with Cloudflare and no problems have occurred:

Have you tried using the Railway one-click setup for Cloudflare? Also, make sure to follow the docs for common problems: https://docs.railway.com/networking/domains#cloudflare-configuration.

Also, is a 502 error the only problem you're getting? Was the domain correctly configured as shown in the image above?