**Goal:** much lower latency for our users, who are all in the Philippines and connect through several different ISPs (PLDT, Globe, Converge and others). Our services and databases are already in Singapore, but every request is being terminated at the **lax1** edge in Los Angeles, which puts a ~0.7 s round trip in front of every request. We would like Philippine traffic to reach **sin1** or **hkg1**. **Setup:** four services across three projects in this account, all deployed in asia-southeast1 (Singapore) for users in the Philippines, with databases also in Singapore. Each is reached on its `*.up.railway.app` domain and some on custom domains (unproxied CNAMEs to the up.railway.app target). All behave the same: every request from the Philippines is terminated at lax1, so each one does Manila → Los Angeles → Singapore → Los Angeles → Manila. The measurements below are from one of them; happy to share project IDs and domains privately. **Evidence,** measured from Manila (ISP: Red Fiber) on 2026-09-07: - Response header on every public domain across the account: `x-railway-edge: lax1` (one `x-railway-request-id: jy8VZqrCRryPdB9j0ubPiw`). - Time to first byte for a 400-byte static file, five samples: 0.70 / 0.74 / 0.70 / 0.72 / 0.73 s. An unauthenticated API 401: 0.77–0.83 s. The other services' domains measure 0.68–0.93 s the same way. - For comparison, a Supabase project in Singapore (behind Cloudflare) answers from the same Manila connection in about 0.10 s. - traceroute to 69.46.46.80 (the anycast IP the domains resolve to), public hops: ``` 4 209.141.5.17 3.4 ms 5 209.141.5.171 150.6 ms <- leaves the Philippines for the US here 6 157.130.245.165 170.3 ms 7 96.87.8.165 168.1 ms 8 66.208.216.74 153.6 ms 9 79.127.195.164 172.0 ms ``` Your POP list (railway.com/.railway/pops) includes sin1 and hkg1, which should be the natural terminations for Philippine traffic. Is the lax1 routing from Philippine ISPs something you can adjust on your side, as in the earlier "Edge routing going through Asia instead of Amsterdam" thread? Happy to run more traceroutes or curl samples from here if that helps. ISPs observed so far: Red Fiber; our other users are on PLDT, Globe and Converge.

Philippine users routed to lax1 edge although services and users are in Asia (sin1/hkg1 exist)

edfrankie

PROOP

a month ago

Goal: much lower latency for our users, who are all in the Philippines and connect through several different ISPs (PLDT, Globe, Converge and others). Our services and databases are already in Singapore, but every request is being terminated at the lax1 edge in Los Angeles, which puts a ~0.7 s round trip in front of every request. We would like Philippine traffic to reach sin1 or hkg1.

Setup: four services across three projects in this account, all deployed in asia-southeast1 (Singapore) for users in the Philippines, with databases also in Singapore. Each is reached on its *.up.railway.app domain and some on custom domains (unproxied CNAMEs to the up.railway.app target). All behave the same: every request from the Philippines is terminated at lax1, so each one does Manila → Los Angeles → Singapore → Los Angeles → Manila. The measurements below are from one of them; happy to share project IDs and domains privately.

Evidence, measured from Manila (ISP: Red Fiber) on 2026-09-07:

Response header on every public domain across the account: x-railway-edge: lax1 (one x-railway-request-id: jy8VZqrCRryPdB9j0ubPiw).
Time to first byte for a 400-byte static file, five samples: 0.70 / 0.74 / 0.70 / 0.72 / 0.73 s. An unauthenticated API 401: 0.77–0.83 s. The other services' domains measure 0.68–0.93 s the same way.
For comparison, a Supabase project in Singapore (behind Cloudflare) answers from the same Manila connection in about 0.10 s.
traceroute to 69.46.46.80 (the anycast IP the domains resolve to), public hops:

 4  209.141.5.17      3.4 ms
 5  209.141.5.171   150.6 ms   <- leaves the Philippines for the US here
 6  157.130.245.165 170.3 ms
 7  96.87.8.165     168.1 ms
 8  66.208.216.74   153.6 ms
 9  79.127.195.164  172.0 ms

Your POP list (railway.com/.railway/pops) includes sin1 and hkg1, which should be the natural terminations for Philippine traffic. Is the lax1 routing from Philippine ISPs something you can adjust on your side, as in the earlier "Edge routing going through Asia instead of Amsterdam" thread? Happy to run more traceroutes or curl samples from here if that helps.

ISPs observed so far: Red Fiber; our other users are on PLDT, Globe and Converge.

Solved

2 Replies

Status changed to Awaiting Railway Response Railway • 29 days ago

brody

EMPLOYEE

a month ago

Thanks for the detailed measurements. This isn't something we're seeing reported widely from the region, so it isn't something we can take on right now. The lax1 termination comes from how the networks between your ISPs and our edge pick a path, not from anything configured on your services, and there's no setting on either side that will move your traffic to sin1 or hkg1.

Status changed to Awaiting User Response Railway • 28 days ago

Railway

BOT

18 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 • 18 days ago

brody

edfrankie

PROOP

18 days ago

Thanks!

Status changed to Awaiting Railway Response Railway • 18 days ago

Status changed to Solved Railway • 18 days ago

Welcome!