Technical
Anycast
Anycast is a routing setup where many servers announce the same IP address and the network delivers each packet to the closest one. It is how one address can answer from Singapore and Frankfurt at the same time.
How it is measured
You measure it by where traffic lands. `traceroute` and ping from different vantage points show different last hops and different round-trip times to the same IP. Many CDNs also say which site answered, for example the `colo=FRA` line at `/cdn-cgi/trace`.
BGP picks the closest announcement by path length and policy, not by kilometres. Measure round-trip time from several networks before you assume the nearest city is the one serving you.
Worked example
An agency pings `app.lumenhq.example` from three probes. The same IP, 198.51.100.20, answers in 11 ms from Frankfurt, 14 ms from Ashburn, and 9 ms from Tokyo. The trace endpoint reports FRA, IAD, and NRT.
Then a carrier changes its peering and the Frankfurt probe begins landing in Amsterdam at 38 ms. Nothing on the origin changed. The announcement path did.
How it differs
Anycast shares one address across many places. A CDN is the product built on top of it that caches and serves content. A CDN can steer with DNS instead, and anycast can front a DNS resolver that caches nothing, so anycast alone promises no caching.
Common errors
Assuming anycast always picks the geographically nearest server. Reading one IP as one machine. Debugging a TCP connection that resets mid-flight when routes shift between sites. Geolocating the IP and concluding the origin is in the US. Blocking an anycast range and cutting off a whole provider.
In practice
Run probes from at least three regions and record which site answered. When a customer reports slowness, ask for the trace output, not just their city. For long-lived connections such as WebSockets, expect an occasional reconnect when routes move.