Indian traffic routed to gru1 (São Paulo) edge for a Southeast-Asia-region service
jackatwork86
FREEOP

22 days ago

Subject:

Project: project-lotus-checkout (ID 3e9904f4-f468-4129-9f5f-f4c76a073897)

Service: web (ID d5d71f43-53cc-4421-aff8-77dd47946116)

Deployment: 12b8514a-8d92-401c-80ad-a4a04893a08d

Region reported by railway status: Southeast Asia

Domain: web-production-0b608.up.railway.app

All requests from India are being anycast-routed to your São Paulo edge instead of Singapore. Six consecutive fresh connections from an Indian ISP returned:

x-railway-edge: gru1 (6/6 requests)

x-hikari-trace: gru1.469d / gru1.jrt2

resolved IP: 69.46.46.100

Measured cost of this from India (curl, 3 fresh connections):

tcp connect = 260ms (1 RTT → São Paulo; India→Singapore should be ~60-80ms)

tls complete = 530ms

ttfb = 1141-1294ms (includes the GRU↔SIN backhaul, ~600ms round trip)

For comparison, from the same connection at the same time, the nearest Cloudflare POP is colo=BOM (Mumbai) with a 55ms TCP connect and 131ms TTFB.

This is a customer-facing e-commerce checkout serving Indian shoppers, so ~1.1s of the page load is this routing. Please advise why India egresses to gru1 for a Southeast-Asia-region service, and whether the Singapore edge can serve this deployment.

Also: no alt-svc header is returned, so HTTP/3 appears unavailable on *.up.railway.app — is that expected?

Solved

1 Replies

Railway
BOT

22 days ago

Your service is confirmed running in asia-southeast1-eqsg3a (Singapore). Railway's edge network uses anycast routing, where the POP a request lands on is determined by BGP network topology and your ISP's peering agreements, not geographic proximity. The X-Railway-Edge header identifies the entry POP, not where your app runs. You can verify the internal leg by sending the X-Railway-Debug: 1 request header, which adds X-Railway-Upstream-Zone to the response, confirming traffic reaches your Singapore deployment regardless of which POP it entered through. Regarding HTTP/3, we support HTTP/1.1 and HTTP/2 at the edge per our published specs, so the absence of an alt-svc header is expected.


Status changed to Awaiting User Response Railway • 22 days ago


Railway
BOT

15 days ago

This thread has been marked as solved automatically due to a lack of recent activity. Please re-open this thread or create a new one if you require further assistance. Thank you!

Status changed to Solved Railway • 15 days ago


Welcome!

Sign in to your Railway account to join the conversation.

Loading...