Cloudflare proxied traffic routed to wrong Railway edge
forsupporter
PROOP

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

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!

brody
EMPLOYEE

2 months ago

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

forsupporter
PROOP

2 months ago

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

forsupporter
PROOP

2 months 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

2 months ago

@Chandrika

brody
EMPLOYEE

2 months ago

Please avoid pinging team members.

forsupporter
PROOP

2 months ago

sorry about that 🙏

twanwalpot
FREE

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.

+11
sam-a
EMPLOYEE

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

forsupporter
PROOP

2 months ago

seems resolved! thanks for helping.

Status changed to Solved brody • about 2 months ago

Railway
BOT

a month ago

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

Loading...