Most people assume an IP address points to exactly one server, in exactly one place. That's true for a typical unicast setup, but it's not the only way networking works.
Anycast breaks that assumption entirely: the same IP address can be announced from data centers on different continents at the same time, and the internet's routing system quietly sends each visitor to whichever one is closest. It sounds like a trick, but it's a well-established technique that powers some of the most critical infrastructure on the internet, and understanding it makes a lot of modern network architecture click into place.
What is Anycast?
Anycast is a network addressing method where multiple, physically separate servers share the same IP address, and routers determine which one a given request actually reaches. Instead of one server owning an address, several do, each announcing it from its own location using BGP (Border Gateway Protocol), the routing protocol that decides how traffic moves between networks.
When a user's request goes out looking for that IP address, it doesn't get sent to a fixed destination. It follows whatever path BGP considers "closest," which in practice usually means the fewest network hops, not necessarily the shortest physical distance.
The user has no idea multiple servers exist behind that single address; from their side, it looks exactly like talking to one machine. This is fundamentally different from a CDN's typical approach of using DNS to hand out different IP addresses to different users; with Anycast, everyone gets the exact same address, and the network layer itself does the routing.
How does Anycast actually work?
The mechanism relies entirely on how BGP already operates. Every server location (or "node") in an Anycast setup announces the same IP range to the internet's routers, using a technique that's otherwise unremarkable in BGP: multiple networks claiming they can reach a destination, and routers picking the best-looking path.
Here's the sequence in practice:
- Multiple data centers, often in different countries, are each given a server (or several) configured with the identical Anycast IP address.
- Each location announces that IP block to its upstream network providers via BGP, typically from its own autonomous system number (ASN).
- When someone tries to connect to that address, their internet service provider's routers see multiple valid paths and pick the one BGP considers best, typically the one with the fewest AS (autonomous system) hops, though real-world path selection also weighs local preference and other BGP attributes.
- The connection lands on whichever physical server that path leads to, usually the geographically or topologically nearest one.
If one of those locations goes offline, its BGP announcement stops, and traffic that would have gone there automatically reroutes to the next-best location. No manual failover, no DNS changes, no propagation delay to wait out. That's the other major reason Anycast is so widely used: the "failover" is a routing table update, not an application-level event.
Anycast and TCP: the part that trips people up
One detail that surprises people learning about Anycast for the first time: it works fine for connectionless protocols like DNS (which runs over UDP) but gets more complicated for stateful, connection-based protocols like a typical HTTPS session over TCP. If BGP routing changes mid-connection and a user's traffic suddenly gets routed to a different physical server than the one that started the TCP handshake, that connection can break, since the new server has no memory of the session.
In practice, BGP paths are usually stable enough during a single connection's lifetime that this isn't a constant problem, and large-scale Anycast CDN operators manage it further with techniques like consistent hashing and careful route engineering. But it's the reason Anycast is most reliably used for short-lived, stateless requests (DNS lookups, the initial connection to a CDN edge) rather than assumed to be a perfect fit for every kind of traffic without any additional engineering.
Where you already encounter Anycast
Anycast isn't a niche or experimental technique. It's the backbone of several systems most people rely on daily:
Public DNS resolvers. Services like Google's 8.8.8.8 and Cloudflare's 1.1.1.1 use Anycast so that a query sent from Tokyo and one sent from Berlin both hit a "local" server, even though it's technically the same address.
Root DNS servers. The internet's 13 root DNS server addresses are each Anycasted across hundreds of physical locations worldwide, which is the only reason the entire DNS system doesn't collapse under a single point of failure. What looks like 13 servers on paper is actually many hundreds of physical machines behind the scenes.
Content delivery networks (CDNs). CDNs use Anycast to route users to the nearest edge node without needing per-user DNS logic, though many also layer additional geo-DNS or latency-based routing on top for finer control.
DDoS mitigation. Because Anycast spreads incoming traffic across many locations automatically, a volumetric attack against one IP gets naturally distributed across every announcing location instead of overwhelming a single server. This "scrubbing" effect is one of the main reasons DDoS protection services rely on Anycast as a core part of their architecture, since it turns a concentrated attack into a distributed load problem across dozens of data centers at once.
Anycast vs. a traditional (unicast) setup
In a standard unicast setup, one IP address maps to one server, in one location, full stop. If that server goes down, whatever's pointing at it, whether that's a DNS record or a hardcoded IP, needs to be updated or fail over manually (or through a separate health-check system) before traffic recovers.
Anycast shifts that responsibility down to the routing layer itself. The "failover" is really just BGP recalculating a path once a location stops announcing the address, which typically happens in seconds rather than the minutes a DNS TTL change might take. The trade-off is complexity: unicast is simple to reason about and debug, while Anycast requires understanding BGP behavior across potentially many networks you don't directly control.
Anycast vs. GeoDNS
It's worth distinguishing Anycast from GeoDNS, since they solve a similar-sounding problem differently. GeoDNS answers DNS queries with different IP addresses depending on where the query appears to originate, sending European users to a European IP and Asian users to an Asian IP.
Anycast, by contrast, hands out the exact same IP address to everyone, and routing (not DNS) decides where the traffic actually goes. GeoDNS is simpler to set up (no BGP, no ASN required) but depends on DNS resolvers reporting accurate location data, which isn't always reliable.
Anycast is more complex to operate but reacts to network conditions in real time rather than relying on DNS lookups that get cached and can go stale.
What it takes to run Anycast yourself
Setting up Anycast isn't something you configure on a single VPS. It requires:
- Your own IP address block, typically allocated by a regional internet registry, since you need address space you control to announce identically from multiple locations
- Your own autonomous system number (ASN), which identifies your network to the rest of the internet's routing system
- BGP sessions with multiple upstream providers, in each location where you want to announce the address
- Servers in each location configured identically enough to serve the same content or service correctly, regardless of which one a given user reaches
Is Anycast something you need?
For most individual websites and small applications, a straightforward unicast IP with a good hosting provider and, if needed, a CDN in front of it, is plenty. Anycast tends to matter most for services that are either latency-critical at a global scale (DNS, real-time APIs) or need serious resilience against distributed denial-of-service traffic.
If you're not running your own network infrastructure with an ASN already, using a CDN or DDoS protection provider that already operates Anycast infrastructure is a far more practical way to get its benefits than building it yourself. If you do have your own ASN and just want a lighter way to run the sessions, look for a provider that supports BGP on VPS plans rather than requiring dedicated hardware in every city, a middle ground between fully outsourcing to a CDN and building dedicated infrastructure everywhere.
Wrapping up
Anycast is one of those pieces of internet infrastructure that works so well most people never think about it, right up until they need to understand why a DNS query "just works" no matter where in the world it's sent from. It's not something every project needs to run itself, but understanding how it works makes a lot of modern network architecture, from CDNs to DDoS protection, much easier to reason about.
Thanks for reading! If you're looking to run this yourself, xTom supports BGP and Anycast sessions on dedicated servers, colocation racks, and VPS plans across its eleven locations, bring your own ASN and prefixes, and xTom peers with you. Beyond that, xTom provides enterprise-grade dedicated servers, colocation services, and IP transit, while V.PS offers scalable, production-ready NVMe-powered VPS hosting perfect for any workload.
Frequently asked questions about Anycast
Is Anycast the same as load balancing?
Not exactly. A load balancer distributes traffic among servers that are usually in the same location. Anycast distributes traffic among servers in different physical locations, based on network routing rather than a load balancer's own logic.
Can a small website use Anycast?
Technically yes, but it requires owning your own IP address space and running BGP sessions with multiple network providers, which is far more infrastructure than most small sites need. Most smaller projects get similar benefits more easily through a CDN or DDoS protection service that already runs Anycast on your behalf.
Does Anycast guarantee the closest server geographically?
No. It routes based on BGP path preference, which usually correlates with geographic proximity but is really about network topology, not physical distance. A user could occasionally be routed to a location that isn't the geographically nearest one if that path scores better in BGP.
What happens if two Anycast locations both look equally good to BGP?
Routers pick one based on their own tie-breaking rules, which can vary by network. In practice, this rarely causes noticeable problems since both locations are, by definition, serving identical content.
Do I need my own ASN to use Anycast?
Yes, in almost all real-world setups. Anycast requires announcing IP space over BGP, which means you need your own autonomous system number (ASN) and IP allocation, not something a typical shared hosting plan includes. You don't necessarily need dedicated or colocation hardware to run the session itself though; xTom, for example, supports BGP sessions on VPS plans in select locations, not just dedicated servers and colocation.
Does Anycast work well for TCP connections like a normal website visit?
It can, but it requires more careful engineering than DNS-style Anycast, since a mid-connection routing change can break an active TCP session. Large Anycast CDN operators manage this with route engineering and consistent hashing; it's not something that works flawlessly out of the box for every protocol.
How is Anycast different from GeoDNS?
GeoDNS hands out different IP addresses based on a visitor's apparent location, using DNS. Anycast gives every visitor the same IP address and lets network routing, not DNS, decide which physical server they actually reach.