2 months 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
2 months 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!
2 months 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.
2 months ago
Please avoid pinging team members.
2 months 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.
2 months 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
2 months ago
seems resolved! thanks for helping.
Status changed to Solved brody • about 2 months ago
a month ago
✅ The ticket Edge routing issue for non-US-East traffic has been marked as completed.
