Would really appreciate someone looking into this issue here, we're are hoping to migrate our db and this is a blocker right now.

Thanks for the headers, that's genuinely helpful for narrowing this down. Two parts:

1. Quick fix on your side first: switch your Cloudflare SSL/TLS mode from Full (Strict) to Full. Our docs call this out, Full (Strict) doesn't behave as intended with proxied domains pointed at Railway.
2. On the routing itself: Cloudflare's Singapore PoP egressing to our us-west2 edge instead of asia-southeast1 is a known origin-pull pattern. I'm raising it with our networking team to see whether traffic engineering can improve the path, and I'll follow up here.

The fact that your *.up.railway.app domain correctly lands on asia-southeast1 confirms our anycast is doing the right thing, so this is specifically the Cloudflare egress leg, not your config.

thanks Angelo! Before I change SSL mode, we front real user PII, so I'd prefer to keep Full (Strict) for the authenticated origin leg unless it's genuinely incompatible. Are you seeing actual cert errors on our domain, or is Full just a precaution?

either way, the blocker for us right now, is Part 2 the SG PoP - us-west2 egress. Please let me know once the networking team can route unisonhq.in to asia-southeast1; we're holding off our DB migration until then. Appreciate your support!!

Hey Angelo & team, just checking in on this when you have a moment. Happy to provide any additional information if needed. Thanks!

Happy friday team! following up for an update here, would really appreciate it!

We recommend removing the Cloudflare proxy (orange->grey cloud) for the time being. They are having a few issues routing correctly to our edge.

Is there anything that you use the Cloudflare proxy for that you can't get from the Railway platform? Would love to know as we're currently prioritizing work on our edge offering.

Thanks Phin. We mainly used the Cloudflare proxy for DDoS/bot protection and origin masking (and we keep Cloudflare R2 for file storage either way). We're going to migrate our prod service + Postgres to asia-southeast1 and switch the domain to DNS-only in the same window, so the SG anycast edge is co-located with the service.

1. Can you confirm our custom domain unisonhq.in will serve directly on your edge in DNS-only mode? (We verified Railway already presents a valid LE cert for it.)
2. In DNS-only, will requests from India reliably enter at asia-southeast1, or is there anything we should pin?
3. Is the Part-2 networking fix (Cloudflare egress → asia-southeast1) still on the roadmap? We'd like to return to the proxied setup later to regain WAF/DDoS once the egress path is fixed.

Yes, in DNS-only mode unisonhq.in will serve directly from our edge, and since we already present a valid certificate for the domain, nothing else needs to change on your side. Entry point in DNS-only follows the same anycast path as your .up.railway.app test, which landed on asia-southeast1 from India, so your custom domain will behave the same once the proxy is off. There is nothing you need to pin. On the Cloudflare egress path, we don't have a timeline to share yet, so DNS-only is the right setup for now and we'll update you here when that changes.