I am from the Philippines but somehow I am being connected to the cdg region based on https://liveview-counter.fly.dev/
I don’t understand why this happens frequently? Latency is very high and unacceptable.. Machine is also in singapore if that helps..
It shouldn’t happen frequently, but Internet routing is a collaboration between multiple companies/entities, and the result of all those decisions combined can be nonintuitive and even a little unsatisfactory sometimes…
Phillipines → Paris is a bit much, though. If you can post a traceroute (mtr) then Fly.io infrastructure staff can often tweak† things at their end to encourage the other participants to select a better overall path.
†I think they sometimes just call the other companies’ network engineers, too, 
.
Hello! This has been happening since last year and I recall I’ve made the same forum post but I’m not sure if this account or some other account. But it has been happening less frequent compared to last year.
Here is mtr
fly app is called base-vm
traderkreios@Jed:~$ mtr -bzo “LSD NABWV” -r -n 66.241.124.67
Start: 2025-05-17T01:12:59+0800
HOST: Jed Loss% Snt Drop Last Avg Best Wrst StDev
i just notice the slow latency when im actually upgrading things that helps latency and get confused why latency just becomes worse
i hope in the future these stuff occur way less because im getting 400-500ms on basic endpoints
cheers
It looks like this traceroute isn’t being routed to cdg. Any chance you also have IPv6 locally? Can you try a mtr to one of our IPv6 addresses instead?
It is often hard to fix routing without observing the client side directly. This is why it’s very helpful to flag these instances, along with traceroutes for us to debug and fix these issues. Thanks for doing that!
Hi team, just checked latency and it’s back to normal. Don’t have much bandwidth to figure stuff out regarding the traceroute would it be okay to just make a new post again when I get routed to cdg again?
one thing i will note is this is the result when visiting https://debug.fly.dev/
In that case it might not be related to Internet routing, and rather the app’s machines in Singapore might have been temporarily unhealthy. Are you observing this behavior (getting routed to cdg) with multiple different apps?
I only run single machine on this app, and it’s in Singapore. I only observe with this app because this is the only app that users hit
Good morning @PeterCxy, just hitting the app now and observing 400ms latencies again. Monitoring live logs the entire time, machine did not ever become unhealthy.
Here are the live logs for the basic endpoint (which when run locally return in 40-50ms)
2025-05-17T03:07:19.086 app[185716eb49ee38] sin [info] INFO klines/services.go:387 Symbol list fetch timing {“duration”: “1.411861ms”, “count”: 0, “exchange”: “bybit”, “timeframe”: “1h”, “category”: “minor”}
2025-05-17T03:07:19.086 app[185716eb49ee38] sin [info] INFO klines/services.go:398 No symbols found for breakout category {“exchange”: “bybit”, “timeframe”: “1h”, “category”: “minor”}
2025-05-17T03:07:19.086 app[185716eb49ee38] sin [info] INFO klines/handlers.go:65 Finished FetcBreakouts {“duration”: “1.489451ms”}
2025-05-17T03:07:19.086 app[185716eb49ee38] sin [info] INFO klines/handlers.go:73 Fetched klines from Redis {“exchange”: “bybit”, “timeframe”: “1h”, “duration”: “1.494561ms”}
Nothing points to very slow processing so I am really perplexed
