23 days ago
o 1 — Turkey / EU traffic (Cloudflare POP: FRA):**
Cloudflare serves the request via FRA (
cf-ray: ...-FRA)Railway then routes the request to Singapore:
x-railway-edge: railway/asia-southeast1-eqsg3a
This causes a big latency jump for our users.
Scenario 2 — Netherlands VPN (Cloudflare POP: AMS):
Cloudflare serves the request via AMS (
cf-ray: ...-AMS)Railway routes correctly to US-East:
x-railway-edge: railway/us-east4-eqdc4a
So this appears to be POP-dependent routing/mapping between Cloudflare and Railway. Cloudflare also shows a scheduled maintenance window for the FRA datacenter today, which might be related (traffic re-routing/peering changes), but the key issue is that FRA -> Railway is consistently selecting the wrong edge (Singapore) while AMS behaves normally.
Could you please check and correct the routing configuration so that Cloudflare-proxied requests coming via FRA do not get pinned to asia-southeast1-eqsg3a?
For reference, here are example headers:
FRA example:
cf-ray: 9bea4258cb787310-FRAx-railway-edge: railway/asia-southeast1-eqsg3a
AMS example:
cf-ray: 9bea4d60ef26970a-AMSx-railway-edge: railway/us-east4-eqdc4a
projectId: 319f636a-c7e6-44d5-b994-d0c7f5876912
serviceId: 983c2a59-c652-4986-b07c-0fa701f9a828
11 Replies
23 days ago
Hello!
We're acknowledging your issue and attaching a ticket to this thread.
We don't have an ETA for it, but, our engineering team will take a look and you will be updated as we update the ticket.
Please reply to this thread if you have any questions!
23 days ago
I've attached this thread to our ticket, thank you for the report!
Thanks for attaching the thread.
Quick update from our side: we no longer see the Singapore edge (asia-southeast1-eqsg3a). However, the issue is not resolved for us because traffic from Europe/Turkey is now consistently routed to US-East:
Turkey test: x-railway-edge: railway/us-east4-eqdc4a
Netherlands (AMS POP) test: x-railway-edge: railway/us-east4-eqdc4a
So while routing changed from “FRA → Singapore” to “EU → US-East”, latency is still significantly higher than our baseline (it has not returned to normal).
Could you please check why Cloudflare-proxied requests from EU POPs are being pinned to a US-East Railway edge, and whether they can be routed to a closer EU edge/region instead (e.g., Frankfurt/Amsterdam/London), or otherwise confirm the expected routing behavior for our setup?
Happy to provide more traces (cf-ray + timings) if useful.
22 days ago
Please avoid pinging team members.
22 days ago
We're experiencing the same issue on our end.
When accessing our Railway-hosted service through Cloudflare proxy from European locations, traffic is being routed to the US-East edge (railway/us-east4-eqdc4a) instead of a closer European edge, resulting in noticeably higher latency for our EU users.
Example from our setup:
cf-ray: 9bee26126e0a9ffb-AMS
x-railway-edge: railway/us-east4-eqdc4a
Would appreciate any updates on whether this is expected behavior for Cloudflare-proxied traffic or if there's a fix in progress for EU routing.
22 days ago
Hi - this should be resolved now. Let us know if you are still seeing any routing issues.
The Railway Team
sam-a
Hi - this should be resolved now. Let us know if you are still seeing any routing issues.The Railway Team
22 days ago
seems resolved! thanks for helping.
Status changed to Solved brody • 22 days ago
16 days ago
✅ The ticket Edge routing issue for non-US-East traffic has been marked as completed.
