How Anycast CDNs Alter Perceived Exit IPs and Client Origin
An architectural investigation into BGP Anycast routing, exploring why edge CDN IPs distort traditional geolocation lookups and how edge proxies handle client origin attribution.
Quick Answer
BGP Anycast (RFC 4786) allows hundreds of geographically distributed datacenters to announce the identical IP address simultaneously. While Anycast terminates user traffic at the closest local edge city, traditional IP geolocation databases display the provider's corporate headquarters (often California). Edge CDNs relay true client IPs to backend origins using CF-Connecting-IP or True-Client-IP headers.
- Identical Global IP: The same IP address exists concurrently in hundreds of global cities.
- Geolocation Centroid Distortion: Databases report provider headquarters rather than physical edge POPs.
- Origin Forwarding Headers: CF-Connecting-IP and True-Client-IP carry the true user IP to backend servers.
1. The Architecture of BGP Anycast Routing
In traditional Unicast routing, each IP address belongs to a single physical device in one specific building.
In Anycast routing, edge routers in Tokyo, London, Sydney, Frankfurt, and New York all announce 104.21.x.x or 1.1.1.1 to their local Internet Exchange Points:
2. Comparison: Unicast vs Anycast vs GeoDNS
Compare the routing architectures utilized by modern high-throughput web platforms:
| Architecture | IP Addressing Model | Routing Decision Layer | DDoS Absorption | Failover Speed |
|---|---|---|---|---|
| BGP Anycast | Single shared IP across all nodes | Layer 3 (BGP AS-Path metric) | Massive (Absorbed locally across hundreds of POPs) | Sub-second (BGP route withdrawal) |
| GeoDNS Unicast | Unique distinct IP per regional datacenter | Layer 7 (DNS Resolver IP approximation) | Vulnerable (Single IP can be saturated) | Slow (Dictated by DNS TTL expiration, 5-60m) |
| Traditional Unicast | Single IP in a single facility | Layer 3 (Fixed physical path) | Poor (All traffic hits one pipe) | Manual failover / BGP re-announcement |
Anycast vs Unicast Resolution Decision Tree
[ Client Sends Packet to Anycast IP ]
|
+-----------------------+-----------------------+
| |
[ BGP Anycast Routing ] [ Geolocation Database Lookup ]
Global BGP chooses shortest Cannot split 1 IP into 300 cities
AS-Path to nearest physical POP Defaults to Corporate Headquarters
| |
[ Physical Termination ] [ False Result: "California" ]
Terminates in London (LHR), (Even if user is in Tokyo or Paris)
Tokyo (NRT), or Frankfurt (FRA) |
| +
v |
Inspect /cdn-cgi/trace colo=XXX <---------------------+
Reveals exact physical airport node
3. Decoding Edge Trace Endpoints (IATA Airport Codes)
Because standard IP geolocation tools fail on Anycast IPs, major edge providers publish diagnostic trace endpoints that expose their internal datacenter airport codes:
4. Proper Origin Header Extraction
When building IP intelligence APIs hosted behind Cloudflare or Fastly, read client IPs from trusted headers:
Frequently Asked Questions
Why does looking up a Cloudflare or Google Anycast IP always show a California address?
In BGP Anycast (RFC 4786), hundreds of datacenters across 120+ countries simultaneously announce the exact same IP address. Because Regional Internet Registries (ARIN) and geolocation databases cannot assign 300 different physical locations to a single IP in a standard lookup record, databases default to the corporate headquarters coordinates (such as San Francisco or Mountain View, California).
How do I find the actual physical city where my Anycast connection is terminating?
You can query the CDN provider's edge trace endpoint. For example, requesting https://www.cloudflare.com/cdn-cgi/trace returns a line such as "colo=LHR" (London Heathrow) or "colo=NRT" (Tokyo Narita), identifying the exact 3-letter IATA airport code of the physical datacenter handling your TCP/TLS termination.
How does an origin web server know the real client IP behind an Anycast CDN?
When an Anycast CDN edge terminates a client TCP connection and forwards the request to an origin server, it attaches dedicated HTTP request headers: "CF-Connecting-IP" (Cloudflare), "True-Client-IP" (Akamai), or standard "X-Forwarded-For" (RFC 7239 Forwarded header). The origin server must inspect these trusted headers rather than the socket TCP peer address.
What is BGP Anycast "route flapping" and how does it affect TCP connections?
Because Anycast relies on dynamic BGP routing, if intermediate internet transit paths shift mid-session, consecutive packets from the same client can be routed to different physical datacenter POPs. While modern networks manage this through consistent routing and border stability, sudden BGP flaps can cause TCP connection resets on stateful protocols.
Data & Technical Sources
- IETF RFC 4786 — Operation of Anycast Services
- IETF RFC 7094 — Architectural Considerations of IP Anycast
- Cloudflare cdn-cgi/trace Documentation — Edge debugging endpoints and IATA airport datacenter codes