When you type 1.1.1.1 into your browser, you reach Cloudflare’s DNS service. So does someone in Tokyo. So does someone in São Paulo. None of you are talking to the same physical server — and yet the IP address is identical. Welcome to anycast, the networking trick that powers most of the modern internet edge.

This post explains anycast clearly, contrasts it with the more familiar unicast model, and walks through the specific implications for IP geolocation, CDN architecture, and DDoS resilience.

The Familiar Model: Unicast

Most IP traffic is unicast — one source talking to one specific destination. When you send a packet to a unicast IP, exactly one machine on the planet has that address, and that’s where the packet goes.

You (203.0.113.1) → Server (104.18.27.89)

Both sides are uniquely identified. The routers between you forward the packet toward the specific machine that has been allocated the destination IP. This is how 99% of IP traffic still works.

The Trick: Anycast

Anycast lets multiple machines, in different locations, claim the same IP address. When you send a packet to an anycast IP, BGP routes you to the nearest instance — by network topology, not geographic distance.

You in NYC (203.0.113.1) → Server in NYC      (claims 104.18.27.89)
You in Tokyo (198.51.100.5) → Server in Tokyo (also claims 104.18.27.89)
You in Berlin (192.0.2.42) → Server in Frankfurt (also claims 104.18.27.89)

All three servers announce the same IP via BGP. Every router on the internet has a route to “104.18.27.89,” but the route’s path varies depending on where the router is. Routers naturally prefer shorter paths, so you get sent to whichever instance is “closest” in network terms.

This isn’t a hack. It’s a defined behavior of BGP and IP routing. RFC 1546 (1993) formalized the concept; production deployment took off in the early 2000s with the root DNS servers and exploded with the rise of CDNs.

Why Anycast Is Useful

1. Locality

The “closest” instance is usually the fastest. Anycast turns the global internet into a regional service: users get fast responses from a server in their own city or country without your application needing to think about regions.

2. Resilience

If one anycast instance goes down, BGP automatically routes traffic to the next-closest instance. The DDoS protection of “absorb attack traffic with hundreds of edge nodes” works partly because of anycast — there’s no single endpoint to overwhelm.

3. Operational simplicity

You publish one IP. Users use one IP. The routing complexity is hidden in BGP. Compare to maintaining “use us-east.example.com for US users, eu-west.example.com for European users” — anycast makes the routing automatic.

Where Anycast Is Used in Practice

A few production examples:

DNS resolvers

The big public DNS resolvers (Cloudflare 1.1.1.1, Google 8.8.8.8, Quad9 9.9.9.9) are all anycast. The IP is the same worldwide; you reach a regional instance based on routing.

CDN edges

Cloudflare, Akamai, Fastly, AWS CloudFront — all use anycast for their public IPs. When you proxy your site through them, end-user requests hit the nearest edge POP automatically.

Root DNS servers

The 13 logical root DNS server addresses are each anycast across many physical instances. (A.ROOT-SERVERS.NET resolves to one IP that’s served from hundreds of locations.)

Routing layer of cloud providers

AWS Global Accelerator, GCP Cloud CDN, Cloudflare Spectrum — all use anycast for client ingress, then forward to regional backend instances.

Anti-DDoS infrastructure

Anycast lets DDoS protection providers (Cloudflare, Akamai, Arbor, Imperva) absorb attacks by spreading them across hundreds of POPs.

Why Anycast Isn’t Used for Everything

If anycast is so useful, why isn’t every service anycast? Several practical reasons:

Stateful connections are hard

TCP sessions are stateful. If BGP routing changes mid-connection (due to a route flap, link failure, or peering change), your packets might suddenly arrive at a different anycast instance — which doesn’t have your connection state. The connection dies.

In practice this is rare enough that most TCP-over-anycast deployments work fine, but for sensitive workloads it’s a real concern. UDP-based protocols (DNS, QUIC, gaming) handle anycast better because each request is independent.

Database writes are hard

You can read from any nearby instance, but writes need to converge on a single source of truth. Anycast helps with read traffic; write traffic still needs traditional routing or distributed-consensus systems.

Cost

Running BGP-speaking infrastructure in multiple locations is expensive. You need transit and peering at each POP, hardware, ops capacity. It’s a fixed cost that only makes sense at scale.

Complexity

Anycast is operationally complex. Diagnosing “which instance did this user hit, and why?” requires looking at traceroute data, BGP table snapshots, and POP-level metrics. Smaller services don’t justify the operational overhead.

The Implications for IP Geolocation

Here’s where it gets interesting from our perspective. An anycast IP doesn’t have a single geographic location. It’s served from many places simultaneously. So what does an IP geolocation API return for it?

Different providers handle this differently:

Some return a “representative” location (often the headquarters of the operator, or the geographic center of the anycast deployment).
Some return “global” or special-purpose codes.
Some return the country of the BGP origin (often the registered country of the AS).

For Cloudflare’s 1.1.1.1, most providers return “United States” because Cloudflare is registered in the US. But the actual server you connect to could be in any of Cloudflare’s 300+ POPs worldwide.

The implication: don’t trust IP geolocation for anycast IPs. The data isn’t “wrong” — it’s just not meaningful in the same way. If you geolocate 1.1.1.1, the answer “Cloudflare’s headquarters in California” is technically correct but tells you nothing about where the actual user is (they’re using 1.1.1.1 as a DNS resolver from wherever they are).

Anycast IPs are usually obvious — they belong to networks like Cloudflare, Google, major DNS providers, big CDNs. If your traffic is showing geolocation for a major CDN’s IP, you’re likely looking at the CDN itself, not your end user. See IP geolocation accuracy for more on this kind of edge case.

How to Tell If an IP Is Anycast

There’s no single header or field that says “I am anycast.” But strong signals:

The IP belongs to a known anycast-heavy network. Major CDNs (Cloudflare, Fastly, Akamai), major DNS providers, well-known root servers — these are almost certainly anycast.
The reverse DNS sometimes hints (a.root-servers.net, one.one.one.one for 1.1.1.1).
Traceroutes from different geographic locations terminate at different network paths, even when the destination IP is identical.

A few IPs to test against if you want to see anycast in action:

1.1.1.1 (Cloudflare DNS)
8.8.8.8 (Google DNS)
9.9.9.9 (Quad9 DNS)
2001:4860:4860::8888 (Google DNS IPv6)

Run a traceroute from your machine to each. The last few hops will be different depending on where you are.

Anycast in Your Own Infrastructure

If you’re not Cloudflare, can you deploy anycast yourself? Yes, but it’s a meaningful undertaking:

You need your own ASN and the right to announce prefixes via BGP.
You need multiple POPs with their own routers and infrastructure.
You need transit / peering at each POP — relationships with upstream networks.
You need monitoring and failover to detect when an instance is unhealthy and stop announcing the prefix from there.

In practice most teams use anycast through a service (Cloudflare, Fastly, AWS Global Accelerator) rather than building it. The barriers to deploying your own anycast network are mostly business, not technical — but they’re real.

Easier alternatives

GeoDNS — return different A records based on the query source. Coarser but operationally simpler.
Cloud provider load balancers — AWS Global Accelerator, GCP’s Global Load Balancing handle the multi-POP routing for you.
CDN proxying — put your origin behind a CDN and let the CDN handle anycast for you.

For most applications, “use a CDN” is the right answer. The CDN already runs anycast; you benefit without building it.

Anycast Edge Cases

A few things to know:

Mid-session route changes

Long-lived TCP connections can break if BGP reroutes them to a different POP mid-flow. Modern QUIC tolerates this better; legacy TCP-heavy protocols don’t.

Anycast for source IPs

Almost all anycast deployments are for destination IPs (server IPs). Anycast source IPs are extremely rare — they break replies because the reply can’t find a unique route back. If you ever see a packet with an anycast source IP, something’s weird.

POP density vs accuracy

A CDN with 100 POPs gives better geolocation accuracy than one with 5, because BGP routing is finer-grained. Cloudflare’s 300+ POPs mean users almost always hit the nearest physical location; smaller CDNs have less precision.

Asymmetric paths

The path from you to an anycast IP may differ from the path back. Most of the time this works fine, but it complicates network debugging.

TL;DR

Unicast = one IP, one machine. The default model.
Anycast = one IP, many machines worldwide. Each user reaches the nearest instance via BGP routing.
Used by every major CDN, DNS resolver, and DDoS protection service.
Great for read traffic, locality, and resilience. Tricky for stateful long-lived connections.
IP geolocation of an anycast IP doesn’t represent any single user’s location.
Building your own anycast is operationally complex; using a CDN that runs anycast is the practical alternative.

If your traffic flows through any major CDN, you’re benefiting from anycast right now without thinking about it. If you ever see “Cloudflare, San Francisco” in your geo data for what should be a user-side IP, that’s anycast in action — and a hint that the IP belongs to the CDN, not the actual user.

Anycast vs Unicast Networking Explained: Routing, CDNs, and Latency