Anycast Explained: How One IP Address Can Live in Hundreds of Places at Once

A ping to 1.1.1.1 from an apartment in Chicago comes back in 9 milliseconds. A friend in Sydney runs the same test at the same moment and gets 11. Ping measures a round trip, the time a tiny message takes to reach a machine and for the reply to come back, and light traveling through fiber-optic cable needs about 150 milliseconds just to make the round trip between Chicago and Sydney, so no single machine could have answered both of them that quickly. Both results are accurate anyway, because the address 1.1.1.1 belongs to a machine in Chicago, another in Sydney, and others in more than three hundred cities around the world, all at the same time. That arrangement is called anycast, and it quietly carries a large share of what you do online, from looking up website names to loading the websites themselves.

Every device on a network has an IP (Internet Protocol) address, the number other devices use to reach it, and normally each address points to exactly one machine, the way a street address points to one house. Engineers call that ordinary arrangement unicast. Anycast deliberately breaks the one-address, one-machine rule: many machines in many places share a single address, and the network delivers each visitor to whichever copy is closest. Emergency phone numbers work the same way. Everyone in the United States dials 911 and everyone in Europe dials 112, and the phone network connects each caller to the dispatch center covering where they're standing, so a caller in Denver reaches a dispatcher in Denver without anyone needing to know which center handles which street. Anycast is one of four ways a network can deliver a message, and the other three make a useful comparison.

Four ways to deliver a message

unicast      one sender to one receiver              a letter to one house
broadcast    one sender to every device nearby       an announcement over a building's speakers
multicast    one sender to everyone who opted in     a radio station, heard by whoever tunes in
anycast      one sender to the nearest of many       a 911 call, answered by the closest center

Broadcast and multicast come with addresses that announce their purpose: a subnet's broadcast address is always its last one, and multicast has its own range starting at 224.0.0.0, as our guide to the reserved IP ranges explains. An anycast address in IPv4 (Internet Protocol version 4, the familiar four-part addresses) looks exactly like any other public address. The sharing lives entirely in how the internet's routers treat the block of addresses it belongs to, so the digits 1.1.1.1 give no hint that hundreds of machines answer to them. It's also the mirror image of NAT (Network Address Translation), the trick that lets every device in a house share one public address on the way out, which our NAT explainer covers; anycast lets many servers share one address on the way in.

To see how routers choose a copy, it helps to know how they find anything at all. The internet is a patchwork of tens of thousands of independently run networks, belonging to internet providers, universities, cloud companies, and large businesses, and they keep one another informed using BGP (Border Gateway Protocol). Each network tells its neighbors which blocks of addresses it can deliver to, which engineers call announcing a route, and the neighbors pass the news along until routers everywhere know at least one path to every block. With ordinary unicast, every announcement for a block leads to the same place. With anycast, the operator announces the same block from every city where it has servers, so the news reaches each router from several directions at once, and each router has to pick one.

A router generally picks the path that crosses the fewest separate networks, adjusted by business rules such as preferring a free connection over a paid one, and it makes that choice on its own, with no central system assigning visitors to sites. Routers in Chicago tend to hear the Chicago announcement over the shortest path and routers in Sydney hear the Sydney one, so each city's traffic flows to its own copy. When an operator opens a new site, it starts announcing the block from there, and nearby routers switch over within seconds without anyone reconfiguring a single device elsewhere. Our guide to supernetting and route summarization explains how routers match addresses against blocks in the first place, and our guide to reading traceroute output shows how to watch the path itself, hop by hop.

Because routing works on blocks, anycast does too. Most of the internet's routers ignore announcements for IPv4 blocks smaller than a /24, a block of 256 addresses written in the slash notation our visual guide to CIDR (Classless Inter-Domain Routing) explains, so an operator who wants a single anycast address still needs a whole /24 and announces all of it from every site. Running anycast on the internet also takes an ASN (autonomous system number), the ID number every independently run network holds, plus a BGP connection with internet providers at every location. That combination is why most organizations rent anycast from a DNS provider or a CDN (content delivery network, a company that keeps copies of websites in cities around the world) and leave the building to specialists. Our free ASN lookup tool shows which network announces any address you're curious about.

In anycast, "nearest" means nearest by network path, which is usually, though not always, nearest on a map. Picture a home in Lisbon whose internet provider connects to a CDN in only two places, London and Frankfurt. The CDN may run a perfectly good site in Madrid, but the provider has no direct connection there, so its routers reach the CDN's block through London, and a request from Lisbon travels to England and back. Mistakes in announcements can do stranger things, like sending visitors in South America to a site in Europe, so anycast operators spend real effort watching where their traffic lands and adjusting announcements when a region drifts to the wrong site. For a visitor, the result is fast most of the time and occasionally puzzling, which is worth remembering when a service that should be nearby feels slow.

Operators accept that occasional strangeness because anycast solves three problems at once. The first is speed. Every 100 kilometers of fiber adds about a millisecond to a round trip, so a site in your own metro area can answer in a few milliseconds where one on another continent would take one or two hundred. The second is resilience: when a site loses power or its servers fail, its routers stop announcing the block, the routers that were sending traffic there switch to the next-best path, usually within seconds, and visitors carry on without changing a setting or even noticing. That only works if a site stops announcing the moment its servers stop working, because a site whose router keeps announcing after the servers behind it fail will swallow every request from its region, so operators wire their announcements to health checks that withdraw the route automatically.

The third problem is attack traffic. A DDoS (distributed denial-of-service) attack floods a target with traffic from thousands or even millions of hijacked devices at once, hoping to overwhelm it. Against a unicast address, every one of those devices aims at the same building. Against an anycast address, each device's traffic travels to its own nearest site, so the flood splits into many smaller streams, and an attack launched mostly from one region overwhelms at worst that region's site while the rest of the world keeps working. That property is a big reason the services the whole internet depends on run on anycast.

The most important of those services is DNS (Domain Name System), the internet's directory, which turns a name like ipcraft.io into the address your computer actually connects to. At the top of DNS sit the root servers, which know where to find every top-level domain, like .com and .org. There are exactly thirteen root server addresses, named with the letters A through M, a limit that dates to the days when the complete list had to fit in one small message of 512 bytes. Thirteen machines could never serve the whole planet, so the twelve organizations that run them use anycast, and those thirteen addresses are answered today by more than two thousand machines in cities on every inhabited continent.

You likely use several other anycast services every day. The public DNS resolvers that answer lookups for anyone, such as Cloudflare's 1.1.1.1, Google's 8.8.8.8, and Quad9's 9.9.9.9, each run as one address served from many cities, which is how a single setting on a laptop works equally well in Tokyo and Toronto. Many CDNs put entire websites behind anycast addresses, so the copy of a page you load comes from a nearby city. The large cloud providers also sell global load balancers, services that spread visitors across many servers, and some of them give an application a single anycast address that works worldwide; our guide to IP address management for multi-cloud and hybrid networks covers keeping addresses straight once a service spans several providers.

DNS suits anycast especially well because of how its conversations work. A typical DNS question and its answer each fit in one small message sent by UDP (User Datagram Protocol), a lightweight method with no ongoing connection, so every question stands alone and can go to whichever site the routes favor at that instant. Web pages usually travel over TCP (Transmission Control Protocol), which sets up a connection that both ends keep track of until it closes. If the routes shift partway through, the next packets arrive at a different site that has never heard of the conversation, and that site resets the connection. Internet routes usually stay put far longer than the seconds or minutes most connections last, so CDNs run websites on anycast without trouble, though a very long download can occasionally break and have to restart.

Each site also serves its own copy of whatever it offers, which suits things that can be copied everywhere, such as DNS answers, images, and cached web pages, better than data that has to live in one place, like the contents of a shopping cart. Copies drift slightly out of step, too. Each site of a public resolver keeps its own memory of recent answers, so a change to a website's DNS records can show up at Google's site in Virginia minutes before its site in Tokyo. That's why our DNS propagation tool labels Cloudflare, Google, and Quad9 as "Global (Anycast)": the tool asks them from IPCraft's server in Ashburn, Virginia, so it hears from their nearby sites, and the label is a reminder that "Google" in the results means Google's machines near Virginia.

Some providers skip anycast and steer visitors with DNS instead. When you look up their name, their DNS servers guess your location and hand back the address of a nearby site, an ordinary unicast address that changes from region to region. Comparing a lookup from your computer with one from a friend in another country makes the difference visible, since an anycast service hands you both the same address and a DNS-steered one hands each of you a different one. Some large services combine the two approaches, using DNS to choose a region and anycast within it.

You can spot anycast yourself with a few simple tests, and the first is the impossible ping from the opening. If an address answers in a few milliseconds from two places thousands of kilometers apart, it can't be one machine. Our free ping tool measures how quickly an address responds from IPCraft's server in Ashburn, so unless you live near Virginia, comparing its result with a ping from your own computer gives you two vantage points without calling a friend overseas. A second test uses traceroute, a tool that lists each router between you and an address: run one from your own computer and another with our free traceroute tool, and an anycast address will sit at the end of two traces that pass through completely different cities.

Our traceroute tool also watches for a telltale anycast pattern. Sometimes a trace reaches its destination, but the final reply comes from an address different from the one the tool asked for, which can happen when equipment in front of an anycast site's servers answers the probe using its own local address. When the tool sees that, it reports the destination as reached, shows both addresses, and notes that this is common for anycast and for multi-homed hosts, servers connected through several network links that each have their own address. Seeing that note on a big public service is a strong hint that the address you asked for lives in many places.

The most direct test is to ask the service where it is. Many anycast DNS services answer a special question about themselves, using a rarely used category of DNS query called CHAOS (named for Chaosnet, an early network from the 1970s), by replying with the name or airport code of the site that handled it. On macOS and Linux, the dig command (short for domain information groper) sends the question, and Windows has nslookup.

Ask an anycast DNS service which site answered

# Which Cloudflare site handled this? (replies with a site code like iad17)
dig @1.1.1.1 id.server CH TXT                            macOS and Linux
nslookup -class=chaos -type=txt id.server 1.1.1.1        Windows

# Which copy of the K root server answered? (replies with a site name)
dig @k.root-servers.net hostname.bind CH TXT

Cloudflare answers with a short site code built from the nearest airport's code, and from IPCraft's server in Ashburn, Virginia, the reply is a code like iad17, for Washington Dulles International Airport, a short drive away, arriving in about a millisecond. The K root server answers with a site name, and it shows how far nearest by network can stray from nearest on a map: of four queries we sent from that same server within a couple of minutes, three came back from ns1.ve-mar.k.ripe.net, a machine in Venezuela about 75 milliseconds away, and one from a machine in Miami, even though our server sits in one of the best-connected data center hubs in the world. Websites behind Cloudflare carry a similar clue in a response header, a label the server attaches to each page it sends, called cf-ray, whose last three letters are the airport code of the site that served the page. This site sits behind Cloudflare, and checking ipcraft.io with our HTTP headers tool, which also runs from Ashburn, showed a cf-ray ending in IAD on one check and EWR, for Newark, New Jersey, more than 300 kilometers to the north, on another, because each new connection can take a different path to a different copy while any single connection stays put.

The same sharing explains why IP geolocation services, the websites that guess where an address is located, so often get anycast addresses wrong. They assign each address a single location, so an address that lives in hundreds of cities gets pinned to one country, often the one where the company registered the block. If a lookup tells you a public DNS resolver sits on the far side of the world while it answers your ping in 10 milliseconds, believe the ping.

Anycast can sound like an IP address conflict on a grand scale, since two devices sharing an address on a home or office network knock each other offline, as our guide to IP address conflicts explains. Routing makes the difference. On one local network, devices find each other directly, using ARP (Address Resolution Protocol) to ask which device has a given address, and two machines that both answer fight over every packet. Anycast copies sit on separate networks with routers between them, and each router picks exactly one path to the shared block, so every packet ends up at exactly one machine. Put two anycast copies on the same subnet, with no router between them, and they become an ordinary conflict.

Anycast works inside a private network too, using the routing a company already runs between its sites. A business with branch offices can give its DNS resolver the same private address at every location, say 10.255.255.53, and have each branch's router announce that address internally. Every laptop in the company then carries one resolver setting and reaches the copy in its own building, and when a branch's resolver fails, its router withdraws the route and that branch's lookups flow to the next-closest office. One setting for every site fits the one-layout-everywhere approach in our repeatable addressing template for branch offices. Kubernetes, a popular system for running applications across a group of machines, uses the same idea on a smaller scale: add-ons such as MetalLB can have several machines announce one service address to the network's routers at once, a setup our guide to IP planning for Kubernetes puts in context.

A related tool solves a narrower problem. VRRP (Virtual Router Redundancy Protocol) lets two routers share one gateway address, with one router holding it and the other taking over if the first fails, so only one machine answers for the address at any moment. Anycast keeps every copy active at once and lets routing divide the traffic, which is why it scales from two sites to two thousand.

IPv6 (Internet Protocol version 6, the newer addressing system with much longer addresses) builds anycast into its rules. On the internet it works the same way as in IPv4, with blocks of /48 or larger announced from many sites, and the big public resolvers have IPv6 anycast addresses too, such as Cloudflare's 2606:4700:4700::1111 and Google's 2001:4860:4860::8888. IPv6 also reserves one anycast address inside every subnet: the very first one, ending in ::, which means "whichever router is on this subnet" and should never be given to an ordinary device. IPCraft refuses to assign that address and skips it when suggesting the next free one, the same way it skips the network and broadcast addresses in IPv4, and our guide to IPv6 address planning covers the rest of the layout.

Anycast addresses confuse the people who find them later, which makes them worth documenting with care. A new engineer who discovers 10.255.255.53 configured on six servers in six cities will reasonably assume someone made a mistake, and a network scan at each branch will find the same address answering everywhere. In IPCraft, an IPAM (IP address management) system, give anycast services a small subnet of their own, such as 10.255.255.0/24, named for that purpose, and record each shared address once, with a description that says it's anycast and a custom field listing every site that announces it. A search for 10.255.255.53 then explains itself, and the next person to find six copies knows the duplicates are deliberate. Our concepts guide covers subnets and address records in more detail.

Back in Chicago and Sydney, both pings told the truth. Each reached a machine in its own metro area, one of hundreds sharing the number 1.1.1.1, chosen by routers that never consulted one another. The next time a tool says an address answered from somewhere unexpected, or a little faster than distance should allow, anycast is the likely reason, and a CHAOS query or a second traceroute will tell you which copy you reached.