Service deployed in Southeast Asia (Singapore) only, 1 replica — no EU deployment. Since ~Jun 4 (no config/deploy change), requests split into two latency tiers, decided entirely by the x-railway-edge header:

• SLOW (>1000ms): railway/europe-west4-drams3a (Amsterdam)
• FAST (<100ms): railway/asia-southeast1-eqsg3a (Singapore)

Same Singapore deployment, same endpoint. Traffic comes from a RapidAPI gateway in AWS ap-southeast-1 (Singapore). When anycast enters via the Singapore edge it's <100ms; when it enters via Amsterdam it hairpins SG→NL→SG-deployment→back at 1000ms+. App handler itself is ~0ms (in-memory cache).

Request IDs (same deployment):

• Slow / Amsterdam: fI6RDVu7SV6aICn7nbOCzg
• Fast / Singapore: 9t_194MkSqG2lj8FipRofQ

From my own machine I can't reproduce it — every request enters via the Singapore edge (traceroute to 66.33.22.11 stays in-region via NTT SG). So the misroute seems specific to RapidAPI's Singapore→Railway path, not my deployment.

Has anyone seen SG-origin traffic (esp. AWS ap-southeast-1) start entering via europe-west4 around early June? Is edge selection something I can influence, or is it purely BGP/anycast on Railway's side? Happy to share full headers / more request IDs.