Cloudflare Tunnel (cloudflared) doesn't let you pin a connector to a specific edge region - the connector reaches Cloudflare's edge via anycast IP addresses, and which physical PoP you land on (ams vs sjc) is decided by whichever network path your local upstream ISP/BGP table considers "closest" at the anycast level, not by anything cloudflared itself configures. The only region override cloudflared exposes is --region us, which is for FIPS compliance and has nothing to do with picking EU vs US edges.

You can try turning the tunnel on and off, hoping Cloudflare will assign routing somewhere closer. But this is neither guaranteed nor permanent (after restarting, routing may look different).

Thanks @p14s3k. Agreed that cloudflared can't pin an edge region and that, region us is irrelevant here.

But the anycast decision is driven by Railway's egress BGP, not my local ISP. The connector runs INSIDE Railway's network (AMS), so which Cloudflare PoP the anycast resolves to depends on how Railway announces/routes its egress traffic.

This is the exact pattern Railway staff have BGP-fixed before:

• US-West app landing on Cloudflare's Singapore edge — staff applied "traffic engineering on the routes via BGP", x-railway-edge went asia-southeast1 →

  us-west2, resolved in minutes: https://station.railway.com/questions/cloudflare-routing-to-another-server-reg-2e902c45

• Amsterdam/Europe traffic routed via Asia acknowledged as an internal ticket and fixed: https://station.railway.com/questions/server-latency-and-slow-response-times-991479b8

Could a Railway staff member check the egress route for this project?

Connector is in AMS but registering to sjc01/06/08 (San Jose). Extra data: I already switched the tunnel to HTTP/2 (TUNNEL_TRANSPORT_PROTOCOL=http2), which removed the p95 spikes, but the ~335ms fixed network leg and residual 502s remain, which is consistent with the cross-continent path, not the app (app responds in ~11ms internally).