Type an IP into your browser in Seoul, and a friend types the same IP in São Paulo, and you are talking to two different machines on two different continents. Not a redirect, not a DNS trick that handed each of you a different address, not a load balancer sitting in the middle splitting traffic. The same 32 bits of destination address, and the packets simply go to different places. Neither of you can tell. Neither of you is supposed to.
That’s anycast, and the first time you really understand what it’s doing it sounds illegal. An IP address is supposed to identify a host. Anycast takes one address and announces it from dozens or hundreds of locations at once, each one insisting to the internet’s routing system that it is that address. The routing system, which has no concept of “the real one,” just shrugs and delivers your packet to whichever claimant is closest.
The lie, and who believes it
The believer is BGP — the Border Gateway Protocol, the routing glue that stitches the internet’s independent networks together. BGP’s whole job is to figure out, for any destination prefix, which direction to send a packet. It learns reachability by listening to its neighbors announce “I can reach this block of addresses,” and it picks among competing announcements using a pile of metrics, the headline one being AS-path length: roughly, the fewest networks to traverse.
Anycast exploits exactly this. You take your address block and announce it from every site you operate. Now every router on the internet hears multiple equally-true claims — “this prefix is over here,” “no, it’s over here” — and resolves them the only way it knows how: pick the closest. Closest in BGP’s sense, which is path length and policy, not literal kilometers. Usually that lines up with geography. Sometimes a quirk of peering sends a packet somewhere that looks absurd on a map. The point is you don’t choose; the routing fabric chooses for every client independently, and the choice is “near.”
None of this is a hack bolted onto the side. RFC 4786, Operation of Anycast Services, standardized the operational practice back in December 2006. The mechanism was always just BGP doing what BGP does, pointed at a deliberately ambiguous destination.
The objection that everyone raised, and why it was wrong
Here’s where it gets interesting, because for years there was a confident consensus that anycast had a hard ceiling: it was fine for stateless, one-shot requests and unsafe for anything else. DNS over UDP? Perfect — a query and a response, no memory, nobody cares which instance answers. But TCP is stateful. A TCP connection lives as a pile of sequence numbers and buffers on one specific machine. If BGP re-converges mid-connection and starts steering your packets to a different anycast instance, that machine has never heard of your connection. It answers your data with a RST. Your session dies.
So the textbook answer became: anycast for DNS, unicast for everything that matters. Reasonable. Also, it turned out, mostly wrong.
The flaw in the worry is its premise — that BGP routes flap around on the timescale of a TCP connection. They don’t. On a healthy network a route, once chosen, is stable for minutes to hours, vastly longer than the few seconds a web request lives. The window in which a re-convergence can land during your connection and change your instance is tiny. When researchers actually measured long-running TCP flows over production anycast CDNs, mid-connection instance switches caused a vanishingly small share of failures — well under a tenth of a percent, dwarfed by the ordinary packet loss and resets that happen on the internet anyway.
The proof is that you are almost certainly using it right now. Cloudflare runs essentially its entire network on anycast, the same address blocks announced from data centers in hundreds of cities, carrying billions of TCP-and-TLS connections — full HTTPS, stateful, exactly the thing the textbook said you couldn’t do. Fastly and others do the same. The “anycast can’t carry TCP” rule didn’t survive contact with people who needed it to and built carefully enough to make it hold.
What you actually buy
Once you accept that stateful traffic survives on it, anycast stops being a curiosity and becomes the cheapest distribution mechanism in networking, because the magic is entirely in the network and nothing in the client.
Proximity is automatic. There’s no geo-DNS guessing a user’s location from their resolver, no client-side server selection. The packet finds the near instance because “near” is literally how routing already works.
Failover is automatic, and this is the part operators love. When a site fails, you withdraw its BGP announcement — or it withdraws itself by going dark. The other sites are still announcing the same address. Routing re-converges in seconds and every client that was landing on the dead site now lands on the next-nearest one, with no DNS TTL to wait out, no record to change, no client that needs to retry a different address. Cloudflare’s own framing is blunt: take an entire data center offline and traffic just flows to the next closest one.
And attacks get diluted instead of concentrated. A volumetric DDoS aimed at one anycast address doesn’t pile onto one machine; it splits across every site announcing that address, each absorbing the slice that’s routing-closest to that chunk of attackers. This is exactly the architecture the DNS root servers moved to after getting flooded in the 2000s — 13 famous addresses, but more than 1,900 physical instances behind them, precisely so no single box is the target.
One address. Many servers. A routing protocol happy to let them all share the name, and a stateful internet that turned out to be far more willing to ride along than anyone expected.