Our edge HTTP logs show recent requests from your client IP arriving at the EU West edge with single-digit ms response times, so the gru1 routing you captured appears to have been transient rather than a persistent misconfiguration. Railway uses anycast, and the edge POP a request hits depends on your ISP's BGP path, not geographic distance, so intermittent routing to a distant POP is an ISP-level decision Railway's edge does not control. To gather the data needed if it recurs, send requests with the X-Railway-Debug: 1 header, which adds X-Railway-Upstream-Zone to the response showing the actual deployment zone that served the request, and run a traceroute to 69.46.46.46 from the affected network while the latency is elevated - the full diagnostic steps are at docs.railway.com/networking/edge-networking.

****Thanks for the detailed explanation. I re-ran the diagnostics you suggested just now, and the routing is still reproducing — not transient:

With X-Railway-Debug: 1 (5 consecutive requests, few minutes ago):

x-railway-upstream-zone: railway/europe-west4-drams3a (correct, confirms the deployment itself is EU)

x-railway-edge: gru1 on 5/5 requests

Latency: 825-889ms on all 5

Traceroute to 69.46.46.46 from the same network:

hop 6 195.22.205.116 9ms (still within Telecom Italia's network)

hop 7 195.22.219.155 209ms (+200ms in a single hop)

hop 8 195.22.219.205 209ms

hop 10 69.46.46.46 201ms (destination)

The jump happens in a single hop right where traffic leaves Telecom Italia's network (AS3269, Italy's largest ISP) — consistent with your explanation that this is a BGP path decision, but it doesn't look like a one-off: it's been consistent across every test today, hours apart, always landing on gru1.

Given this is a major Italian ISP (Telecom Italia/TIM) rather than an obscure network, is there a specific peering/IXP presence Railway could add (or already has) that would make this path more attractive for Telecom Italia's routers? Also happy to test again at a different time of day if that would help distinguish routing-table flapping from a stable misconfiguration.

One more thing worth flagging: I'll likely need to upgrade to the Pro plan soon, but this latency issue is making me hesitant to commit to it until it's resolved — it would help a lot to get this sorted out before I do.

We tracked this down and fixed it. Your ISP, Telecom Italia, reaches us through its Sparkle/Seabone backbone, and Seabone was choosing our São Paulo edge for your traffic, which is what added the ~850ms round trip through South America. We have adjusted our routing so that Seabone now enters our network in Europe.

From Telecom Italia connections in Italy we are now measuring roughly 30 to 40ms to our edge, down from 800ms plus. Please re-test with X-Railway-Debug: 1. You should see x-railway-edge reporting a European POP rather than gru1, and the fixed latency floor gone.

Thanks for the detailed traceroutes, they made this much faster to pin down.

Thank you for the short time of your response. Now is working properly and the latency is low. Thank you