One specific fallback-routing question: Fly’s own announcement says SIN edges can try another region when they cannot connect directly to a distant Machine, and flyio-debug reports that intermediate node in fbn: Smarter fly-proxy routing is now available in all regions . Two successful but slow direct Philippine GET /health requests on Sep 25 both had fbn: null: (1) idle dev app, Angeles City, 13:59 UTC, 2,634 ms first byte, 01M3CDT8QS5SX3J7RR9XM7V7R8-sin, edge-dp-sin1-c11b → worker-lsh-lax1-042e; (2) production app, Manila, 14:19 UTC, 2,228 ms, 01M3CEYV5QFJPHS2CG4SRCXY7C-sin, same SIN edge → worker-lsh-lax1-6857. Fly’s SIN successful-response edge p95 was 2.6–3.3 s during 14:05–14:30 UTC while NRT was ~0.45 s and our handler ~0.36 s. Can you locate where these requests waited and explain why fallback did not engage? Is there a supported temporary routing adjustment for SIN→LAX? Our game also uses WebSockets, so please say whether that adjustment would cover them.