Routing issues across Railway apps and railway.com from Korea: LAX/SIN instead of Tokyo

I’m trying to use Railway for users in South Korea with consistently low latency, but performance deteriorated enough that I canceled my Pro subscription. I recently returned to investigate and found Korean connections entering through Los Angeles or Singapore instead of the Tokyo ingress I had previously observed. This is not limited to one application: I also tried multiple Railway applications and railway.com itself and observed routing problems, although the detailed measurements below cover one representative application. The issue was present in my latest tests on September 25, 2026; please investigate routing across the affected Korean networks and whether Tokyo ingress or comparably low-latency routing can be restored.

Scope and representative resource

• Representative application: https://app-production-25776.up.railway.app/
• Reported upstream zone: railway/asia-southeast1-eqsg3a
• Destination IPv4: 69.46.46.86 in every recorded test below
• Observation window: September 25, 2026, 02:19:39–02:25:10 UTC (11:19:39–11:25:10 KST)
• All recorded requests returned HTTP 200. No failed deployment was identified.
• Exact onset and timestamped last-known-good result: unknown.

Based on my additional tests across multiple apps and railway.com, please investigate this as a potentially broader routing issue rather than limiting the investigation to a service’s configuration.

Recorded measurements

Requests were made directly to the Railway-provided hostname using IPv4 and X-Railway-Debug: 1. Times are cumulative from the start of each curl request. Timestamps come from HTTP response Date headers.

| Source | UTC time | Edge | TCP connected | TLS complete | TTFB |

|---|---|---|---:|---:|---:|

| KT fixed-line, Korea | 02:19:39 | lax1 | 144.6 ms | 296.1 ms | 616.4 ms |

| SKB fixed-line, Korea | 02:20:15 | sin1 | 151.2 ms | 282.0 ms | 405.6 ms |

| SKT 5G, Korea | 02:21:45 | sin1 | 149.1 ms | 299.6 ms | 426.5 ms |

| LG U+ 4G, Korea | 02:22:54 | sin1 | 139.5 ms | 276.0 ms | 447.8 ms |

| (informational) Latitude.sh Tokyo datacenter | 02:25:10 | hnd1 | 83.5 ms | 131.9 ms | 210.8 ms |

Relevant response headers:

Korea Telecom fixed-line — 2026-09-25 02:19:39 UTC
x-railway-request-id: nK6QlX-xTZC37pelAXC71g
x-railway-edge: lax1
x-hikari-trace: lax1.z1hw,lax1.v9kt,sin1.nzn2

SK Broadband fixed-line — 2026-09-25 02:20:15 UTC
x-railway-request-id: vw78llW0R86DQmqgoB_USg
x-railway-edge: sin1
x-hikari-trace: sin1.tr00

SK Telecom 5G — 2026-09-25 02:21:45 UTC
x-railway-request-id: haCYGu0URa6Ka_qoJH0Vcg
x-railway-edge: sin1
x-hikari-trace: sin1.tr00

LG Uplus 4G — 2026-09-25 02:22:54 UTC
x-railway-request-id: eagO17jZT4-K1rsxacI7Nw
x-railway-edge: sin1
x-hikari-trace: sin1.hs0s,sin1.tr00

Latitude.sh Tokyo — 2026-09-25 02:25:10 UTC
x-railway-request-id: mbgvxY28RU-MbTtEV7rehQ
x-railway-edge: hnd1
x-hikari-trace: hnd1.df23,hnd1.2zrd

All five responses reported server: railway-hikari and x-railway-upstream-zone: railway/asia-southeast1-eqsg3a.

Reproduction and uncertainty

Run from an affected Korean connection:

curl -4 -sS -D - -o /dev/null -H 'X-Railway-Debug: 1' -w '\nIP=%{remote_ip} connect=%{time_connect}s TLS=%{time_appconnect}s TTFB=%{time_starttransfer}s\n' https://<omain-name>.up.railway.app/

KT’s trace shows LAX ingress followed by SIN. The Tokyo test reaches hnd1 at the same destination IP, demonstrating that Tokyo ingress is available from at least that network.

Singapore ingress is also a concern: the three Korean SIN samples took 406–448 ms to first byte. I understand that the origin is in Singapore; my question is why Korean connections no longer terminate at Tokyo before forwarding to the origin.

These are individual samples, not controlled benchmarks. They do not establish the cause, isolate application processing time, or prove how much Tokyo ingress would improve Korean latency. My observations across other apps and railway.com suggest broader scope but do not establish a shared underlying cause. No traceroute/MTR results or configuration fixes are included.

Requested investigation and referral

The AI assistant first recommended contacting Railway support because the observed routing degradation warranted network investigation and similar routing reports had previously been addressed by Railway. The concrete blocker is that client measurements do not reveal why ingress selection changed.

Please investigate routing for these Korean networks, including any relevant BGP, prefix, peering, or transit changes. Please assess both KT’s LAX detour and the other networks’ SIN ingress; moving KT to Singapore alone would not address the full concern. The named application should serve as a diagnostic reference for this broader investigation.

Prepared with Railway's support template (v1).