Hawaii traffic seems to route through Sao Paulo
18thletter
HOBBYOP

15 hours ago

I'm in Hawaii (Hawaii island), and my traffic seems to be getting routed through Brazil on every request.

From Hawaiian Telcom in Hawaii, every Railway-hosted property answers from the gru1 (Sao Paulo) edge -- including railway.com and docs.railway.com, so it isn't specific to my services. My services are in us-west2, so requests cross to Brazil and hairpin back to Oregon, adding ~1s to every request.

[myhost] / railway.com / docs.railway.com -> x-railway-edge: gru1

RTT from the same host (so not my last mile):

69.46.46.39 (Railway anycast)    243.1 ms

1.1.1.1     (Cloudflare)                  13.0 ms

8.8.8.8     (Google)                       56.2 ms

Path — Lumen picks it up locally, then hauls it to Brazil:

2  72.253.4.3     4.9 ms   Hawaiian Telcom

4  4.79.8.25     12.4 ms   AS3356 Lumen, Honolulu

6  8.242.0.2    243.0 ms   AS3356 Lumen, São Paulo

Traffic is already on Lumen in Honolulu at ~12ms, then travels ~230ms to Sao Paulo to reach AS400940. I checked other regions and saw normal figures (US 0.12 - 0.18s, EU 0.26 - 0.34s, BR 0.47s); Hawaii is the outlier. IP is visible to 323/326 RIS peers, so propagation is fine.

Fronting with Cloudflare only fixes half -- client -> edge drops to ~12ms (their Honolulu PoP) but the response still says x-railway-edge: gru1 and total only falls 1.29s -> 0.51s, because their backbone also lands on gru1.

Anyone know a workaround or fix?

Awaiting User Response

4 Replies

Railway
BOT

14 hours ago

Your diagnostics show the path from Hawaiian Telcom through Lumen (AS3356) reaching Railway via São Paulo rather than a US mainland path, which is driven by how your transit provider's BGP routing selects a path to the destination. This is not specific to your services or anything configurable on your side. Cloudflare in front partially helps because it terminates the client connection at its Honolulu PoP, but the origin fetch still follows a similar transit path, explaining the partial improvement you measured.


Status changed to Awaiting User Response Railway about 14 hours ago


Railway

Your diagnostics show the path from Hawaiian Telcom through Lumen (AS3356) reaching Railway via São Paulo rather than a US mainland path, which is driven by how your transit provider's BGP routing selects a path to the destination. This is not specific to your services or anything configurable on your side. Cloudflare in front partially helps because it terminates the client connection at its Honolulu PoP, but the origin fetch still follows a similar transit path, explaining the partial improvement you measured.

18thletter
HOBBYOP

14 hours ago

Yep, you got it right. Still need help on this.


Status changed to Awaiting Railway Response Railway about 14 hours ago


11 hours ago

Thank you for your report, we are looking into this.


Status changed to Awaiting User Response Railway about 11 hours ago


2 hours ago

Hello,

We've withdrawn from a global transit provider (Lumen) in Sao Paulo which has now fixed this issue. Thank you for the report!


Welcome!

Sign in to your Railway account to join the conversation.

Loading...