Anycast Explained: How One IP Address Lives in Many Places

Most IP addresses answer the obvious question: which machine is this? An anycast address refuses to. It is configured on servers in dozens or hundreds of separate buildings, every one announcing it to the internet, and the packet you send arrives at exactly one of them. Which one is not your decision, and not the operator's either. It falls out of the routing table.

That single property is why the DNS root zone still works, why a content network can absorb a flood, and why a latency test against a big public address says little about the service as a whole.

What anycast actually is#

Start with the delivery models. Unicast is one address, one destination, and nearly every address you look up is doing that. Multicast sends one packet to every receiver subscribed to a group. Anycast is one address with many candidate destinations: the network delivers each packet to exactly one, and never tells the sender which.

The idea was written down in RFC 1546, Host Anycasting Service, an IRTF Informational document from November 1993. It imagined a distinct anycast address space that hosts would treat specially. That is not what the internet built.

What shipped instead needs no new protocol at all. An operator configures the same address on servers in many locations, and each location announces the covering prefix into BGP as if it were an ordinary network. Routers do what they always do: pick one best path per destination prefix and forward. Nothing in the routing system knows the prefix is special. The service is distributed; the routing is conventional. Our explainer on BGP and internet routing covers that machinery; anycast changes one detail, that the prefix originates in more than one place.

Two documents cover the practice. RFC 4786, Operation of Anycast Services (December 2006), is BCP 126 and holds the operational guidance. RFC 7094, an IAB document from January 2014, works through the architectural consequences, including the awkward ones.

Nearest means nearest in routing#

Anycast is usually described as sending you to the nearest server. That word is doing a lot of work, because the thing choosing has no idea where anything is.

A router selects among candidate paths using BGP's best-path process: local preference first, then AS path length, then origin and further tiebreakers. Local preference is a policy value the operator sets by hand, typically to prefer a peer over paid transit. AS path length counts networks crossed, not kilometres. Not one step in that sequence measures distance, latency, or capacity.

The outcome usually looks geographic anyway, because networks are built roughly along the lines people live along. But the exceptions are ordinary: a network with no local peering may hand your traffic to a transit provider that carries it past a nearby site to a larger one two countries away. This is also why geolocating an anycast address is close to meaningless: the registration has a location, the answering machine has a different one, and an IP lookup can only ever show you the first.

How a query reaches a root server#

The DNS root is the clearest example of the pattern working at scale. There are 13 root server identifiers, lettered a through m, run by 12 independent organisations. That is a fixed, published number every resolver ships with, so the root cannot grow by adding addresses.

It grows by anycast instead. As of 4 September 2026, root-servers.org reported the root server system running 2,005 operational instances behind those 13 identities. Your resolver sends its query to one of the 13 addresses; the routing table decides which of the 2,005 machines actually receives it.

Public resolvers work the same way. Google states that "anycast routing directs your queries to the closest Google Public DNS server", and that a query to 8.8.8.8, 8.8.4.4, or one of its IPv6 addresses is routed to the nearest location advertising that address. Our DNS records lookup reaches Cloudflare's resolver over DoH the same way: whichever anycast site is nearest, returning the authoritative state rather than one country's cached view.

Local nodes and global nodes#

RFC 4786 gives operators a vocabulary worth borrowing. A global-scope anycast node announces its reachability so that it is potentially visible to the whole routing system. A local-scope node announces in a way that makes it visible only to a subset of that system.

In practice a local node lives inside one ISP or hangs off one internet exchange, with its announcement tagged so it never propagates further, so only that network's users reach it. Global nodes sit on well-connected transit and catch everyone else. The mix is what makes the economics work: a local node can be a single modest server sized for one network's traffic, because if it fails its route simply disappears and those users fall through to a global node. Withdrawing the route is the failover.

RFC 4786 does attach a warning. Rapid advertisement and withdrawal oscillations cause operational problems, so a node should enforce a minimum delay after a withdrawal before it may re-advertise. A server that keeps flapping in and out of the routing table is worse than one that stays down.

All of this is visible from outside. The prefixes an operator announces, and the size of the footprint behind them, are exactly what our ASN Explorer lists for a given network.

The TCP problem#

Anycast suits protocols where a whole transaction is one packet out and one packet back. DNS over UDP on port 53 is the canonical fit: nothing is remembered between exchanges, so it does not matter that consecutive queries land on different machines.

TCP is the opposite. A connection is state, and that state lives on one specific server. RFC 7094 is blunt about the consequence: most stateful transport protocols, TCP included, "do not understand the properties of anycast; hence, they will fail probabilistically, but possibly catastrophically, when using anycast addresses in the presence of 'normal' routing dynamics." If the path shifts partway through and your packets arrive at an instance holding no state for that session, the session is reset.

Yet a very large share of the web is served over anycast TCP right now, because routes are stable over the timescale of an HTTPS request. A path that changes a handful of times a day almost never changes during the second your connection is open. RFC 7094 acknowledges those deployments while noting that evidence suggests the practice is not "safe" in the traditional and architectural sense, and points to short-lived transactions as the case where operators reasonably accept the risk.

The practical reading: brief connections are fine, and long-lived ones are where this occasionally bites. A multi-hour download or a persistent session is the traffic most likely to meet a mid-flight route change. Our TCP versus UDP post covers why the two behave so differently.

Anycast on IPv6#

IPv6 is the one place anycast appears in an addressing specification, and the specification's main point is that there is nothing to see. RFC 4291 assigns anycast addresses out of the unicast address space, using any of the defined unicast formats, which leaves them syntactically indistinguishable from unicast addresses. A node has to be explicitly configured to know that one of its own addresses is being used for anycast.

There is no reserved prefix, no flag, no bit set. Whether an address is anycast is a fact about how it was deployed, learnable only by being told or by watching the behaviour.

The specification does reserve one form: the Subnet-Router anycast address, which is a subnet prefix followed by zeros in every remaining bit. A packet sent to it is delivered to one router on that subnet, and every router is required to support it for the subnets it is attached to. It is a way to reach "a router here" without knowing which one. If IPv6 addressing is new ground, what is my IPv6 address is the gentler start.

Three things anycast is not#

It is not a load balancer. A load balancer knows how loaded each backend is and splits traffic accordingly. Anycast knows nothing and splits nothing deliberately. Load lands where routing policy sends it, so one large network changing its preferences can move a slice of your traffic to a site you did not choose. Operators steer by editing announcements, prepending an AS path or withdrawing a route, which is coarse and slow next to a real balancer.

It is not DNS-based geo-steering. Those are two mechanisms at different layers, frequently used together. Geo-steering happens while the name is being resolved, often with EDNS Client Subnet, which Google describes as passing part of the client's address so that name servers can return results based on the user's location rather than the resolver's. Anycast happens afterwards, on the address that resolution already returned.

It is not DDoS protection on its own. What it provides is dispersion: a flood from many sources splits across many sites, each absorbing its share instead of one link carrying everything. That is a real structural advantage and a large part of why content networks build on anycast, but the capacity still has to exist at each site. Our post on DDoS attacks covers what actually absorbs one.

What this does to your testing#

Every diagnostic you run against an anycast address describes one instance: the one your packets reached. That is a real measurement, and it does not generalise.

Our response time checker makes that limit explicit. Its probes run from whichever Cloudflare colo handled the request, it reports which colo that was, and it says outright that every probe in a run came from the same one. For figures from another part of the world, repeat the test from there rather than reading more into a single run.

The same caution applies to propagation checking. Our DNS propagation checker queries several public resolvers at once, and the geographic spread comes from the regional ones. The resolvers marked as global anycast are answering from wherever our request entered their network, which is near our edge rather than near you. Worth knowing before reading a row as evidence about a country. The mechanics of why an update rolls out unevenly are in DNS propagation explained.

Traceroute has the same limitation in a more visible form. A trace ends at the site you happened to reach, and two traces from two continents can share no hops at all without either being wrong. Our guide to reading a traceroute is the companion here.

If you need to know where a service answered you from, ask the service: many expose the answering site in a response header or a diagnostic record. Failing that, look at the routing rather than the address, at which AS originates the prefix and where that network is present.