I just ran nslookup and couldn't find a CNAME record on polivey.com.

Try removing then re-adding the record in Cloudflare.

Thanks! I'll try removing and re-adding the CNAME.

Quick question: my CNAME is behind Cloudflare proxy (orange cloud).

If Cloudflare is proxying, external nslookup won't show the raw CNAME —

it'll show Cloudflare's A records instead.

Could this be why Railway can't verify the CNAME?

I'll set the record to DNS only (grey cloud) temporarily,

re-add the CNAME, wait for propagation, and report back.

https://railway.com/project/fd968c45-b47c-421f-ad2e-d72befeef38e/service/7e82ba06-705f-4d8b-a686-826da3f5b35f

Nevermind you're right. Sorry.

If it's proxied, then as long as you know that the CNAME record is entered correctly in Cloudflare, the custom domain shoulud be validated automatically in Railway.

> Could this be why Railway can't verify the CNAME?

No. Just tested myself and documentation says so. (

Got it, thanks for clarifying — I'll leave the Cloudflare proxy on.

Here's the actual issue: the custom domain status in Railway UI

keeps flipping between green (Active) and yellow (Warning/Pending)

every few seconds. It's never stable.

Also, a direct bypass test hitting Railway's edge without Cloudflare

in the path still returns 502:

$ curl -Iv https://polivey.com/api/health --resolve polivey.com:443:151.101.2.15

• Connected to polivey.com (151.101.2.15) port 443
• TLS handshake succeeded < HTTP/1.1 502

So TCP/TLS to the Railway edge is fine (cert is issued),

but the edge returns 502 as if the service mapping for polivey.com

isn't registered internally.

The default domain (web-production-2cbecd.up.railway.app) works perfectly,

so the service itself is healthy.

Could you check the internal edge mapping for polivey.com?

I suspect it's stuck in a partial state — that would also explain

the green/yellow flipping in the UI.

Service URL: https://railway.com/project/fd968c45-b47c-421f-ad2e-d72befeef38e/service/7e82ba06-705f-4d8b-a686-826da3f5b35f

It's also flipping between "Cloudflare proxy detected" (with a green cloud) and "Waiting for DNS update" for me as well. Checking with the team right now as we speak.

You shouldn't need to specify a port.

Also, make sure that the port your URL is mapped to is the same port your application is listening on.

Thanks for confirming — I can reproduce the flipping too.

Quick check on my side regarding ports:

• Dockerfile sets ENV PORT=3000 and EXPOSE 3000
• Railway Networking shows Port 8080 currently
• Default domain on port 8080 works fine

I'll change Networking port to 3000 and add PORT=3000 to Variables

so everything aligns at 3000 as you suggested.

Will redeploy and test.

Meanwhile, appreciate you checking the DNS flipping with the team.

Flipping or not, your DNS is not set up correctly.

(Your domain is currently resolving to a Fastly IP)

It works now! Thank you so much 🙏

Root cause was exactly the port mismatch you flagged:

• App was listening on 8080 (Railway's auto-injected PORT)
• Default domain routed to 8080 ✓
• But custom domain was routing to 3000 (from EXPOSE 3000 in Dockerfile)

Fix:

• Added PORT=3000 to service Variables
• Set Networking port to 3000
• Now app listens on 3000 and both domains route to 3000 → all consistent

Still curious about the UI flipping between "Cloudflare proxy detected"

and "Waiting for DNS update" though — that made diagnosis really confusing.

Please pass that on to the team as a UX improvement opportunity 🙏