I’m on a free account and I’m trying to evaluate Fastly for a basic setup: an origin server in Frankfurt and one in Singapore. I’m trying to route Asian/Oceanian traffic to Singapore and European traffic to Frankfurt. But it has been very painful to get results. My conditions look like this:
When I try this out in my own browser (in Europe) it seems to work fine and contact the Frankfurt origin. When I curl on my server in Singapore it also seems to correctly route to Singapore.
But when I run a larger test on speed vitals it is a mess. From Paris requests seem to be routed to Singapore while from Sweden they go to Frankfurt.
NOTE: The x-origin header I’m adding myself and holds the AWS region that serves the request in the end.
NOTE: I’v disabled caching completely, I’m trying to measure the Fastly network without caching.
The geo information comes from the client IP, see more at Geolocation | Fastly Developer Hub
We are using the database from Digital Element; if there is some inaccuracy in the database, you might see the not-expected continent code.
I suggest you add some debug response header to tell what is the client IP that generates the unexpected result, like in Fiddle Fiddle - Fastly
You can leave us a message of the result and our support team might can have a check with digital element.
That’s a good idea. The internet is a pretty complicated place, and we have varying amounts of understanding and control over where traffic comes from and where it goes.
In the best scenario, you use a non-apex domain, such as www.example.com and route traffic to Fastly using a CNAME in your DNS. This allows us to intelligently route traffic and ensure that users are connected to their most suitable Fastly POP. You can then read which POP they landed on using server.region or server.datacenter and choose an appropriate origin server.
If you use an apex domain like example.com, the routing of the user to Fastly is done using a less intelligent mechanism that’s not tunable by Fastly. The user will still most likely get to the right POP, and you can still use the POP identity as a way to decide which origin to use, but there will be more weird edge cases and exceptions.
Finally, using geo variables is a totally separate solution and uses a mapping of IP addresses to physical locations maintained by a third party. We don’t have any control over the accuracy of that, and while it’s normally pretty good at the country level, it can be notably inaccurate for cloud hosted IPs, which is a problem for synthetic testing services like the one you were using.
