Fly Edge mismatch

Hi! I have an app in Frankfurt region. I have a user in Moscow that complains about latency. I see through Grafana that user’s requests go to Hong Kong edge so he get 600-800ms latency on each request because of path Moscow → Hong Kong → Frankfurt.
When I do request from Georgia I get 100ms latency which is ok.
So what can we do to fix how edge is chosen for user? He don’t use vpn etc so it should work as expected and choose nearest Europian edge

Hi Alexey,

From reading the problem statement it seems that the problem is related to the routing. Here are a few points you could consider -

  1. It could be possible that internet routing from Russia to some European countries may be diverted due to various reasons, such as geopolitical factors, internet censorship, surveillance, traffic filtering, network topology, and peering agreements between Internet Service Providers (ISPs).
    So in this case, you need more users from that region to validate if this is the case as you mentioned only one user in the problem and ask this user in Moscow to provide a traceroute report and their IP address. This will help you understand the exact path their requests are taking and identify any potential network bottlenecks or routing problems. (This is my assumption as you mentioned two users from neighbouring countries)

  2. Verify Anycast Routing: Fly.io uses Anycast routing to automatically direct users to the nearest region. Make sure Anycast is enabled for your app by checking your app’s configuration also ensure that the DNS settings for your domain are correctly configured.

  3. Depending on your app’s architecture and requirements, you may want to consider deploying your app to an additional region which is closer to Moscow. This can help reduce latency for users in that region, as requests would be routed to the nearest data centre.

I hope this might help you.

Regards,
Devansh

Hi, thanks for your reply!

  1. I thought so that’s why I bought virtual machine in Russia to check it and it wasn’t the case so at least from one machine traffic goes normally.
    I have asked user to print traceroute and here it is:
  2. I think it is enabled by default and works for most of cases as expected. How can I check it?
  3. I think Frankfurt is already the nearest to Moscow

If there is any other user in that region I think it might help more to understand the route.

To check if anycast is enabled and working for a particular service, you can perform a traceroute from multiple geographical locations and check if the routes converge to different servers based on the location of the test. See, these online traceroute tests may not provide conclusive evidence but can give you a good indication of whether anycast is enabled and working as expected for a particular service.

Frankfurt is close but maybe can you try to host some other region close to Frankfurt.

Hi! I’ve asked some other users to check and they got fra region and another one got ams, so generally it’s ok.
With that problem user we also checked region here at the bottom and he also got Hong Kong https://liveview-counter.fly.dev/. So looks like problem is not in my app but in anycast routing Fly uses. That user doesn’t have problems with accessing any other European resources, only those which deployed via Fly.
I previously had Warsaw region and that user also was routed to it through Hong Kong

1 Like

Hi @Alexey

Based on the information it sounds like the internet service provider MTS has some inefficient routing for the fly.io anycast IP addresses. You can verify this by checking which internet providers your users are using for both users with and without issues. If it’s mostly MTS users then it’s likely just the one ISP having routing inefficiencies.

This could possibly be fixed but would require communicating with MTS to investigate and resolve. It’s possible fly.io may be able to communicate with them but there’s no guarantees. I’d suggest that your users that use MTS get in touch with them and let them know of the issue.

1 Like

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.