Cloudflare proxied traffic routed to wrong Railway edge
forsupporter
PROOP

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-FRA

  • x-railway-edge: railway/asia-southeast1-eqsg3a

AMS example:

  • cf-ray: 9bea4d60ef26970a-AMS

  • x-railway-edge: railway/us-east4-eqdc4a

projectId: 319f636a-c7e6-44d5-b994-d0c7f5876912
serviceId: 983c2a59-c652-4986-b07c-0fa701f9a828

Solved

11 Replies

Railway
BOT

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!

brody
EMPLOYEE

23 days ago

I've attached this thread to our ticket, thank you for the report!

forsupporter
PROOP

22 days ago

@Brody any estimation ? how can i track status of ticket ?

forsupporter
PROOP

22 days ago

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.

forsupporter
PROOP

22 days ago

@Chandrika

brody
EMPLOYEE

22 days ago

Please avoid pinging team members.

forsupporter
PROOP

22 days ago

sorry about that 🙏

twanwalpot
FREE

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.

+11
sam-a
EMPLOYEE

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

forsupporter
PROOP

22 days ago

seems resolved! thanks for helping.

Status changed to Solved brody • 22 days ago

Railway
BOT

16 days ago

✅ The ticket Edge routing issue for non-US-East traffic has been marked as completed.

Loading...