Anycast: One IP, Many Places

A pattern keeps showing up in this section. DNS could hand you a nearby server's address (GeoDNS). A CDN put a reverse proxy close to you. Both quietly assumed the same magic: a way to reach the nearest of many identical places. This lesson is the deepest, most elegant version of that magic — and it works at a layer so low it feels like cheating.

It's called anycast, and the idea is almost absurd the first time you hear it:

Put the exact same IP address on servers in dozens or hundreds of locations around the world at once — and let the internet's own routing deliver each user's packets to the nearest one. No DNS trick, no client-side logic, no code. The routing fabric itself becomes a global load balancer.

Wait — isn't an IP address supposed to identify one machine? For normal traffic, yes. Anycast breaks that assumption on purpose, and the payoff is enormous. From a single advertised address you get four gifts at once: every user reaches a nearby server (low latency), traffic distributes itself by geography with zero configuration ("routing as load balancing"), a DDoS attack gets spread thin across every location instead of crushing one box, and if a location dies, traffic reroutes itself to the next-nearest within seconds. This is the trick behind global CDNs, the DNS root servers, and 1.1.1.1 — and by the end of this lesson you'll understand exactly how one address can live in a hundred places, and why that's one of the most powerful ideas on the internet. Let's break the one-IP-one-server rule.

To feel what's strange (and wonderful) about anycast, hold up its ordinary sibling first. Every IP address you've dealt with until now has been unicast:

• Unicast — one IP, one machine. The address maps to one specific interface on one specific server, sitting in one specific place. Send a packet to it and the internet's routing carries it to that device, wherever in the world it is. One address → one destination. Simple, and what you'd expect.

Now the twist:

• Anycast — one IP, many machines. The exact same IP address is configured on many servers, in many locations — each location called a Point of Presence, or PoP. Send a packet to that address, and the internet routes it to the nearest PoP advertising it. One address → many possible destinations → and the network silently picks the closest one for you.

That's the whole conceptual leap: the same address is deliberately duplicated across the planet, and "where does this packet go?" gets answered by proximity instead of by a fixed location. A user in Tokyo and a user in Frankfurt can send packets to the identical IP and reach completely different servers — each one nearby — without either of them knowing there's more than one. It's like a phone number that connects you to whichever office is closest, instead of always ringing one headquarters. But how does the network know which PoP is nearest, with no central coordinator telling it? That's where the internet's routing protocol quietly does something beautiful.

The internet isn't one network — it's tens of thousands of separate networks (autonomous systems) stitched together, each run by an ISP, a company, or a cloud. They tell each other "here's which chunks of the internet I can reach" using a protocol called BGP — the Border Gateway Protocol — the routing glue that holds the whole internet together.

Normally, a given block of IP addresses is announced from one place, so BGP builds one path to it. Anycast does one deliciously simple thing: it announces the same IP block from every PoP at once. Now routers all over the world hear many different paths to that same address — and every router runs BGP best-path selection, which (among other rules) prefers the route that crosses the fewest networks. So each router, independently, forwards your packet along its shortest path — which naturally leads to the PoP nearest to you. No central brain decides this; it emerges from thousands of routers each picking their own best path. That's the beautiful part: the routing already-running-everywhere becomes the load balancer, for free.

One important subtlety to get right, because it's a classic "well, actually": "nearest" means network-nearest, not necessarily geographically nearest. BGP chooses by AS-path length and routing policy (who peers with whom, and the economics of those relationships) — which usually lines up with geography, but not always. A user might get routed to a PoP that's slightly farther on a map because that's the shorter path through the networks. Close enough almost every time — but it's the topology, not the miles, that decides. Which means, remarkably, you get all of this by doing almost nothing: announce one address from everywhere, and routing hands each user a nearby copy.

Sit with what just happened, because it's the core idea of this lesson and it's genuinely elegant. You didn't set up a load balancer. You didn't write any logic to decide who goes where. You didn't return different answers to different users. You just put the same address in many places — and the internet's routing spread your traffic across those places by geography, automatically. Users in Asia land on Asian PoPs; Europeans land on European PoPs; Americans land on American PoPs. The routing fabric itself became a global load balancer.

That's why the enum called this "routing as load balancing," and it's worth appreciating how different this is from every balancing mechanism you've met. A normal load balancer is a box you run that actively decides where each request goes. Anycast has no such box and no such decision — the distribution is a side effect of how the internet already routes packets. It's load balancing that falls out of the laws of physics of the network, at planetary scale, with zero moving parts you have to operate.

And because it's woven into routing itself, it comes with superpowers a normal load balancer can only dream of — resilience and attack-resistance that are free consequences of the design, not features you bolt on. The best way to believe all of this is to watch it happen: users finding their nearest PoP, a PoP dying and traffic healing around it, an attack getting spread thin. So let's put the whole planet on a map and let you break it.

Anycast is one of those ideas that sounds like magic until you watch the packets move — so below is the whole planet, and every point of presence on it advertises the same IP address.

First, just watch users find their nearest PoP — each one's traffic routes to the closest point of presence, automatically, no configuration anywhere. That's "routing as load balancing" in motion. Then break things on purpose, because the failure behavior is where anycast truly shines. Kill a PoP and watch its users instantly reroute to the next-nearest one — that's failover, with no DNS change and no client action, just BGP re-converging. Launch a DDoS and watch the flood spread across every PoP so no single one drowns — then flip the whole thing to unicast and watch that same attack crush the one lonely server while faraway users crawl across the world to reach it. By the time you've killed a PoP and survived an attack, you'll understand in your bones why the DNS roots, 1.1.1.1, and every CDN on earth are built on this.

Everything you just watched comes down to four benefits — and the striking thing is that they all fall out of the same single act of announcing one address from everywhere. You don't configure them separately; you get all four at once:

• Low latency — the nearest PoP. Each user's request reaches an edge a few milliseconds away instead of crossing an ocean. The single biggest lever for a fast global site.
• Routing as load balancing. Traffic distributes itself by geography with zero configuration — the routing fabric is the balancer, at global scale, with no box to run and nothing to tune.
• DDoS absorption. This one is beautiful. An attack aimed at an anycast IP gets spread across every PoP advertising it — so each PoP only ever sees its local slice of the flood. A botnet's firepower gets divided by the number of PoPs instead of concentrated on one machine. It's why anycast networks shrug off attacks that would instantly vaporize a single server: Cloudflare autonomously absorbed a record 31.4 terabits-per-second attack in late 2025, spread across its 330-plus locations. No single box could survive a fraction of that — but three hundred boxes each taking a sliver can.
• Automatic failover. If a PoP goes down, it simply stops announcing the address (BGP withdraws the route), and every router in the world re-converges to the next-nearest PoP within seconds. Traffic heals around the failure on its own — no DNS change to propagate, no health-check config, no human paged. The single-point-of-failure lesson's dream, delivered by the routing layer itself.

Latency, distribution, attack-resistance, and self-healing — four wins, one address. That ratio is why anycast is one of the highest-leverage ideas in all of infrastructure. Which naturally raises the question: who actually uses it? The answer is: the load-bearing walls of the internet.

Anycast isn't an exotic optimization for a few giants — it's the quiet foundation under the pieces of the internet that have to work everywhere, all the time:

• The DNS root and TLD servers. Remember the puzzle from the DNS lesson — how can just "13 root servers" serve the entire planet? Now you have the second half of the answer. Caching filters out most lookups, and anycast handles the rest: each of those 13 logical letters is actually hundreds of physical nodes, all advertising the same IP via anycast. Thirteen addresses, hundreds of boxes, whole world served.
• The public DNS resolvers. Google's 8.8.8.8 and Cloudflare's 1.1.1.1 answer billions of queries a day from hundreds of locations — all on that one memorable address, thanks to anycast.
• Every CDN's edge. Here's the payoff of last lesson: a CDN like Cloudflare has every server in its 330-plus-city network advertising the same IP addresses. That "reverse proxy close to the user" you learned about? Anycast is how your packet finds it. You send to one IP; routing drops you at the nearest edge PoP; the reverse proxy there does its job (TLS, caching, WAF) and, if needed, fetches from origin.

And that last point reveals how anycast fits with everything else: anycast is coarse. It gets your packet to the right region / PoP — but it can't do least-connections or weighted balancing across the actual servers inside that PoP. So each PoP runs a real load balancer (the reverse proxy and the L4/L7 balancers from the last lesson and the next section) to spread requests across its machines. The clean division: anycast picks the PoP; the load balancer picks the server. Two layers of balancing — global and coarse from routing, local and fine-grained from a real LB — stacked together. That's how a request actually finds a specific CPU on the other side of the world.

Anycast sounds like free magic, so it's important to know its sharp edges — the honest limits that shape where you can use it:

• Long-lived stateful connections are the classic risk. Since which PoP you reach is a BGP decision, a route change in the middle of a connection can suddenly send your packets to a different PoP that knows nothing about your session — and the connection breaks. That's why anycast is a perfect fit for UDP (stateless DNS — one query, one answer, no session to lose) and short-lived requests, and was historically avoided for long-lived stateful TCP. In practice, routes are stable enough and big providers engineer "stickiness," so Cloudflare runs its entire HTTP edge over anycast TCP just fine — but understanding why it's a concern tells you where the risk lives.
• You don't control which PoP a user hits. It's the internet's routing decision, driven by peering and economics — so a user can occasionally be routed to a suboptimal PoP. You get good distribution, not precise control.
• You can't just switch it on in your app. Real anycast needs BGP, your own autonomous system, and your own IP block announced from many locations — serious infrastructure. In reality you get anycast by using a provider (Cloudflare, Fastly, a cloud's global load balancer), not by writing code. It's something you rent, not configure.

It's also worth pinning down how anycast relates to GeoDNS from the DNS lesson, because they're cousins that solve the same problem at different layers. GeoDNS returns a different IP based on where the DNS query came from — the choice happens at the DNS layer. Anycast uses one IP everywhere and lets Layer-3 routing make the choice. Same goal — send users to the nearest place — different mechanisms, and the biggest systems often use both together. Neither is "the right one"; they're complementary tools for the same job.

The trade-off in anycast is unusually lopsided in its favor, but it's real and worth stating plainly:

Anycast trades fine control for free global distribution and resilience.

What you give up is precision. You don't get to choose exactly which PoP or which server serves a given user — BGP decides, occasionally routing someone to a farther-than-ideal PoP, and a mid-connection reroute is a (small, manageable) risk for long-lived stateful connections. You can't hand-tune it the way you tune a load balancer, and you can't run it without either a serious network operation or a provider.

What you get is staggering for the price of announcing one address from many places: nearest-PoP latency, automatic geographic load balancing, a DDoS's firepower divided across your whole network, and self-healing failover — all from the routing fabric, with zero client-side logic and nothing to actively operate. And because it's coarse, it doesn't fight your other tools; it composes with them — anycast picks the region, a real load balancer picks the server inside it.

So the mental model is: anycast is the blunt, planetary-scale instrument — you give up the fine knobs, and in exchange the internet's own routing hands you global reach and resilience for one IP. For the specific job of "be everywhere, be near everyone, survive attacks and failures," nothing else comes close for so little. You don't reach for it to balance ten servers in one data center; you reach for it to be present on the whole planet at once.

"One IP always means one server." With anycast, one IP is advertised from many servers in many locations, and the network routes you to the nearest. Unicast = one; anycast = many.

"Anycast is a DNS / GeoDNS trick." No — it's a Layer-3 routing mechanism (BGP) using the same IP everywhere. GeoDNS returns different IPs at the DNS layer; anycast uses one IP and lets routing decide. Cousins, different layers.

"Anycast routes to the geographically nearest PoP." Not exactly — to the network-nearest (fewest AS-hops / routing policy), which usually but not always matches the map.

"You configure anycast in your application." No — it needs BGP + an autonomous system + an IP block. You get it by using a provider (CDN/cloud), not in app code. You rent it.

"Anycast can't do TCP." It can (Cloudflare's whole edge is anycast TCP). The real caveat is long-lived stateful connections, where a mid-session route change could break the session.

"Anycast replaces load balancers." No — it's coarse (per-region routing); a real LB inside each PoP does the fine-grained balancing. Anycast picks the PoP; the LB picks the server.

"Anycast is just about lower latency." It also gives free DDoS absorption (the attack is spread across every PoP) and automatic failover (BGP withdraws a dead PoP and traffic reroutes) — often the bigger wins.

Five minutes and you can literally observe the same IP address answering from different places. Predict first: if you ping 1.1.1.1 from home and then from a phone on cellular (or a VPN in another country), do you think the latency will be the same — and are you even hitting the same machine?

1. Feel two PoPs. Run ping 1.1.1.1 from your normal connection and note the latency. Now do it from a different network — a phone on cellular, or a VPN set to another country. The latency changes, because you're reaching a different PoP of the same anycast address. Same IP, different server, different distance.
2. See the different paths. Run traceroute 1.1.1.1 (or 8.8.8.8) from two locations and compare the last few hops. Identical destination IP, but the routes — and the final router — differ. You're watching BGP send the same address down two different paths.
3. Read the PoP by name. Open https://cloudflare.com/cdn-cgi/trace and look at the colo= field — it's a three-letter airport code for the PoP that served you (SIN, FRA, IAD…). Reload it over a VPN in another region and watch that code change — the same address, served from a different nearest PoP. That's anycast, caught in the act.

That third one is the clincher: one address, and the network quietly picked a different nearest copy depending on where you stood. Once you've seen the colo code change, "one IP, many places" stops being a slogan and becomes something you've watched with your own eyes.

One address, a whole planet:

• Anycast advertises the same IP from many PoPs (via BGP), and the internet's routing delivers each user to the network-nearest one — versus unicast, where one IP is one machine.
• It's "routing as load balancing": traffic distributes itself by geography with no box to run and no logic to write — the routing fabric is the balancer.
• Four wins from one address: nearest-PoP latency, automatic geographic distribution, DDoS absorption (an attack is spread across every PoP), and self-healing failover (a dead PoP stops announcing and traffic reroutes in seconds).
• It powers the internet's foundations: DNS roots (how 13 letters serve the planet), 8.8.8.8 / 1.1.1.1, and every CDN edge. It's coarse, so it composes with a real load balancer: anycast picks the PoP; the LB picks the server.
• The trade-off: you give up fine control (BGP decides; long-lived stateful TCP is the sharp edge) for free global reach and resilience from one IP.

And with that, you've assembled almost the entire toolkit for getting bytes across the internet: addresses and layers, TCP and UDP, DNS, HTTP, TLS, proxies, and now anycast. There's one humble primitive left — the quiet workhorse that runs underneath all of it, on every packet, making sure the bytes that arrive are the bytes that were sent. Because networks don't just lose packets; they occasionally corrupt them, flipping a bit in transit — and something has to catch that, cheaply, billions of times a second. That's the last piece of the networking puzzle: checksums — trust, but verify.