Verified: 2026-10-17By Alex Chen (Lead BGP Architect)RFC 4786 & Edge Architecture8 Min Read

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:

Tokyo User:BGP routes to Tokyo Equinix (NRT POP) -> 2 ms latency.
London User:BGP routes to London Telehouse (LHR POP) -> 3 ms latency.
Both Users Connect To:1.1.1.1 (Exact same IP address).

2. Comparison: Unicast vs Anycast vs GeoDNS

Compare the routing architectures utilized by modern high-throughput web platforms:

Comparative Overview of Internet Traffic Distribution Models
ArchitectureIP Addressing ModelRouting Decision LayerDDoS AbsorptionFailover Speed
BGP AnycastSingle shared IP across all nodesLayer 3 (BGP AS-Path metric)Massive (Absorbed locally across hundreds of POPs)Sub-second (BGP route withdrawal)
GeoDNS UnicastUnique distinct IP per regional datacenterLayer 7 (DNS Resolver IP approximation)Vulnerable (Single IP can be saturated)Slow (Dictated by DNS TTL expiration, 5-60m)
Traditional UnicastSingle IP in a single facilityLayer 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:

Cloudflare Edge Trace:curl -s https://www.cloudflare.com/cdn-cgi/trace | grep "colo"
Output Interpretation:colo=SFO (San Francisco) | colo=FRA (Frankfurt) | colo=NRT (Tokyo)

4. Proper Origin Header Extraction

When building IP intelligence APIs hosted behind Cloudflare or Fastly, read client IPs from trusted headers:

Cloudflare Client IP Header:request.headers.get('cf-connecting-ip')
Akamai / Fastly Header:request.headers.get('true-client-ip')
Standard Forwarded Header:request.headers.get('x-forwarded-for')?.split(',')[0].trim()

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