Anycast, one IP, many servers, and how BGP picks the closest

There's a beautiful trick at the intersection of IP routing and DNS. Instead of giving each server its own IP, you give many servers the same IP and let the internet's routing pick which one a user reaches. The internet, via BGP, naturally routes the user to the topologically closest copy. The result feels like magic: a single address that's somehow always nearby.

This trick is called anycast. It's how Cloudflare's 1.1.1.1, Google's 8.8.8.8, and most modern CDNs work. It's also how some game-hosting companies improve latency and resilience.

This article explains how anycast actually works.

Unicast vs anycast, visualized

Same IP. Different physical servers. BGP routes each user to whichever announcement is closest in network terms. The internet, via BGP, automatically routes each user to whichever instance has the shortest AS path. From the user's perspective, they connect to 192.0.2.42. They have no idea which physical server they reached.

What's not magic

A few clarifications:

Anycast isn't load balancing in the usual sense. Once a user's path is established, all their traffic to that IP goes to one specific instance, not balanced across all.

Anycast doesn't optimize for application performance. It optimizes for BGP topology. The "closest" server is the one with the shortest AS path, not necessarily the one with the lowest ping.

Anycast can be unstable. If BGP routes shift mid-connection, a TCP session could end up flipping to a different instance, breaking the session. This is why anycast is mostly used for stateless protocols.

Anycast doesn't help if all instances are in the same region. You need real geographic distribution.

What anycast is great for

DNS. DNS queries are mostly stateless (single UDP packets). Anycast for DNS is a natural fit: the user gets a nearby resolver, the resolver gives back an answer, done. No long-lived sessions to worry about.

This is why public DNS resolvers (1.1.1.1, 8.8.8.8, 9.9.9.9) are all anycast. The "8.8.8.8" you reach in Tokyo is a different physical server than the "8.8.8.8" you reach in Berlin.

CDN edge nodes. HTTP requests are usually short and stateless. A CDN can use anycast to direct users to the closest edge, where they fetch the content. If the connection happens to flip to a different edge mid-fetch, TCP fails and the browser retries (usually invisibly).

Routing announcements for DDoS protection. Many DDoS scrubbing services use anycast: the protected IP is announced from many scrubbing centers, so attacks get spread across them.

NTP, certain root DNS servers, some other distributed services.

What anycast is bad for

Long-lived sessions. If BGP routes shift (which they do, occasionally), an established TCP connection might suddenly route to a different anycast instance. The new instance doesn't know about the existing connection, so the TCP handshake fails. The application has to reconnect.

For HTTPS-fetching a webpage, this is rare and recoverable. For a game with a 4-hour session, it's painful.

State that needs to be consistent across instances. If user A and user B are connecting to the same anycast IP and the application needs them to see each other (e.g., a chat room), but they're routed to different instances, the instances must share state. This is hard.

Inbound for game servers. Most games hold long sessions and have state per user. Anycast typically doesn't work for "the game server itself." It can work for game proxies that forward traffic to a real backend.

How operators deploy anycast

The operational steps:

1. Obtain a portable IP block (one not tied to a specific upstream). This is usually a /24 or larger that you can announce yourself.
2. Get an ASN (or have your provider announce on your behalf).
3. Have presence in multiple locations, each with BGP peering and the ability to announce your prefix.
4. Configure each location's router to announce the prefix. If using a global cloud provider with anycast support, this is often a few clicks.
5. Run the same service in each location. Identical software, similar config, but each in their own region.

Once announcements are in place, BGP does the rest. Users get routed to whichever location's announcement reaches their region as the "best path."

Tuning: you can use AS path prepending to make some locations less attractive than others. You can use BGP communities offered by upstreams to influence routing. This is fine-grained adjustment.

The "great anycast" myth

Some marketing implies anycast automatically gives you the best routing. It doesn't. The closest BGP path isn't always the lowest-latency path. A few cases:

Asymmetric paths. Your incoming traffic goes to instance A, but the response goes via a different path. Latency is the sum, not the average.

Suboptimal peering. The BGP topology might route a user in Boston to a Frankfurt instance via a long path, even when there's a Boston instance available. Happens if peering is good for Frankfurt and poor for Boston.

Anycast is only as good as your locations. If your "global" anycast has 3 locations in North America and 1 in Frankfurt and 0 elsewhere, users in Asia get terrible performance.

BGP topology vs geography. BGP doesn't know geography directly. It uses AS path length and operator policy. Sometimes the path it picks is geographically weird.

For these reasons, how anycast performs depends on how it's deployed. Cheap anycast (a few locations, sparse peering) is mediocre. High-quality anycast (many locations, dense peering, careful tuning) is excellent.

A specific example: Cloudflare 1.1.1.1

Cloudflare's public DNS resolver. The IP is 1.1.1.1. The service is anycast from 300+ Cloudflare locations worldwide.

When you query 1.1.1.1:

• Your network's BGP topology determines which Cloudflare PoP your packet reaches.
• Cloudflare receives the query at that PoP, resolves it, responds from the same PoP.
• Latency is typically 1-15 ms for users in regions with Cloudflare PoPs.
• The same IP works for a user in Tokyo and a user in São Paulo, each hitting different PoPs.

This works because DNS is stateless and short-lived. No session-sticky requirement.

Anycast for game hosting

For traditional game servers (Minecraft, Valheim, etc.), anycast doesn't work directly. Long sessions, stateful, players in one server should see each other.

What does work:

Anycast for the login / portal layer. Player visits website, gets routed to a nearby anycast edge that handles the auth, then directs them to a specific (unicast) game server. Web-style operations benefit from anycast; the game itself doesn't need it.

Anycast for matchmaking. A matchmaking endpoint can be anycast. It handles short-lived requests and returns the IP of an actual game server.

Anycast for DNS-only resolution. Resolve play.myserver.com to the closest data center's IP. The game session is then unicast to that specific server. Closer to GeoDNS than true anycast, but the effect is similar.

Specialized "TCP/UDP anycast" with session affinity. Some advanced setups use anycast addresses but maintain session state across PoPs so that even if BGP shifts mid-session, the session continues. This is expensive engineering and used only by sophisticated operators.

For typical game hosts: anycast is most useful for the surfaces around the game (web, login, matchmaking, status pages) and less useful for the game server itself.

Cost and complexity

Anycast requires:

• Multiple locations (each has fixed costs).
• BGP peering at each (operational overhead).
• Synchronized software deployment.
• Monitoring across locations.

This is more complex than running one big unicast instance. For services that benefit (DNS, web edges, DDoS protection), the cost is justified. For services that don't (small game servers), it's overkill.

Hyperscalers (Cloudflare, Google, Amazon) deploy anycast at enormous scale and pass the benefits to their customers. Smaller operators have to choose carefully.

The DDoS protection angle

A specific anycast benefit: DDoS attacks against an anycast IP are naturally distributed.

Anycast naturally splits attacker traffic across all your PoPs in proportion to BGP distance. A 200 Gbps attack against 20 PoPs becomes 20 separate ~10 Gbps attacks, each absorbable. This is one reason DDoS protection services almost always use anycast for their protected IPs. The architecture itself is part of the defense.

When anycast confuses you

Operational notes:

Tracing to an anycast IP can be confusing. Different traceroutes hit different instances. The path you see depends on where you're tracing from.

Logs at the destination show many sources. A single anycast service sees traffic from worldwide users, all hitting the same instance's IP. You can identify which "location" handled which user via your own internal tagging.

Latency tests can be misleading. Pinging 1.1.1.1 from Berlin and from Tokyo gives different numbers because you're pinging different physical servers.

A summary

Anycast is the elegant trick of announcing one IP from many places. BGP and the internet's routing topology do the work of getting users to a nearby instance. The result: a single IP that's "near" everyone, with built-in redundancy and natural load distribution for stateless workloads.

It's not a silver bullet. It's a great fit for some applications, a poor fit for others. Used well, it shapes the modern internet's performance. Used badly, it's expensive complexity without much benefit.

For hosting companies, anycast is part of the toolkit for public-facing surfaces (DNS, web, matchmaking). For game servers themselves, unicast usually wins.

Coming up

We've covered some of the internet's most sophisticated routing tricks. Next, we shift to something more mundane but operationally critical: GRE tunnels, the unsexy technology that makes scrubbing services and many remote-server-protection schemes actually work.