What Is Anycast? Why One IP Address Has Many Locations
Anycast lets servers in many places offer the same public IP address. Internet routing sends each user to a site selected from the routes visible to that user's network. People often call this the "nearest" site, but nearest means the routing system's choice. It does not necessarily mean the physically closest site or the one with the lowest delay.
This is common for public DNS resolvers, security proxies, and content delivery networks (CDNs), which serve content through distributed servers. A lookup therefore describes a service running in multiple places, rather than one machine in one city.
How can one IP address be served from many places?
With normal unicast routing, an address usually leads toward one service location. With anycast, networks announce the same address range (IP prefix) from several locations. Each routing announcement tells other networks that the range can be reached through the announcing network. Border Gateway Protocol (BGP) is the set of rules used to exchange those announcements. Routers select among the available routes according to routing policy, path attributes, peering, traffic engineering, and failures.
For example, a user in Warsaw may reach a European site while a user in Chicago may reach a North American site, even though both connect to the same IP address. That outcome depends on network topology and policy, not geography alone. A BGP view can show advertised routes, but it does not reveal every hop in the end-to-end packet path.
| Signal | How to read it |
|---|---|
| Same IP, many sites | The IP identifies a global service, not one physical server. |
| Routing decides the site | Routes visible from the user's network help determine which site receives the traffic. |
| Failures move traffic | If one site is withdrawn or deprioritized, traffic shifts to another site. |
How does anycast work for 8.8.8.8?
Google documents that its public DNS resolver at 8.8.8.8 uses a global anycast network. AS15169 is a Google ASN associated with the service's routes. A DNS query uses the same destination address, but BGP leads each user's network toward an available Google site according to the routes visible from that network. The linked IP Lens results reflect the registration and routing observations currently available, so a routing row may be absent or show a covering prefix rather than this exact service route.
A user in one region can therefore reach a different site from a user elsewhere. The IP service address remains the same, while the observed route, city, traceroute, and latency can vary by observer, measurement source, and time. No single city shown for 8.8.8.8 describes every request to the service.
| Part of the lookup | What it means |
|---|---|
| Destination IP | Every user queries 8.8.8.8. |
| Example Google ASN | AS15169 identifies Google's network; a lookup may show a broader range containing the service addresses. |
| Reached site | Routing from the user's network selects an available site. |
| City and latency | Results can differ by vantage point and data source. |
Why does anycast location data disagree?
Geolocation databases try to attach one location to an IP prefix. For anycast, there is not one correct city. The same address is active in many regions at the same time, and different providers choose the headquarters location, a common site, one site observed by their probes, or a broad country-level answer.
That is why an anycast IP shows different cities, coordinates, or accuracy radii across sources. If IP Lens shows an Anycast tag or conflicting locations, read the location as service context rather than the exact place where one request was handled.
Traceroute results can disagree for the same reason. Each observer starts from a different network and may enter a different anycast site. Routes can also change over time. A traceroute describes one observed path; it does not prove the server's physical location or predict the path seen by every other user.
For more general location caveats, see why an IP location can show the wrong city.
Why do public DNS and CDN addresses behave differently?
Public DNS resolvers such as Quad9's public DNS resolver result for 9.9.9.9 and Google's public DNS resolver result for 8.8.8.8 are designed to be reached from many networks around the world. A CDN address works similarly when it serves cached content or proxy traffic from many edge locations.
For investigations, that means the address describes infrastructure, not a person or a single origin server. A public DNS address points to the resolver that was queried. A CDN or reverse-proxy address points to the provider in front of a site. Neither should be treated as the visitor's physical location by itself.
If your application is behind a CDN or proxy, confirm which address is the actual client by checking trusted forwarding headers and proxy configuration. See Finding the real client IP.
How can I tell whether an IP address uses anycast?
Start with the IP Lens anycast tag and the service operator's documentation. Then compare observations from more than one network or region. Useful clues include:
- Traceroutes from different regions finish through different network paths or sites.
- Latency and apparent geolocation vary by observer while the destination IP stays the same.
- The operator documents that it announces the same prefix from multiple locations.
One traceroute, one geolocation result, or one ASN lookup is not enough by itself. It shows the result from that data source or observation point, not the service's full footprint.
How should I use anycast signals in IP Lens?
Treat anycast as a warning that location, latency, traceroute, and reverse DNS describe one edge of a distributed service rather than the whole service. Read it alongside the registered holder, announcing Autonomous System Number (ASN), reverse DNS, tags, and your own logs.
Anycast is not suspicious by itself. It is a normal design choice for highly available global services. It becomes important when you are trying to explain why location data disagrees, why two users reached different sites for the same IP, or why a CDN address appears in place of a user address.