Geo-Routing Strategies: Directing Users by Location

Geo-routing is the practice of directing CDN requests to edge servers based on the geographic location of the user. When a visitor in Frankfurt requests a web page, geo-routing ensures the request is handled by a nearby European edge server rather than one in Singapore or Sao Paulo. This geographic affinity reduces network round trips, minimizes latency, and ensures that users interact with the closest available copy of the content.

Modern geo-routing extends beyond simple proximity calculations. CDNs must account for GeoIP database accuracy, DNS resolver location mismatches, regulatory compliance requirements, and the distinction between geographic closeness and network-path efficiency. This guide examines each geo-routing strategy, its implementation mechanisms, accuracy limitations, and the practical considerations that determine which approach to use.

How Do GeoIP Databases Power CDN Routing Decisions?

GeoIP databases are the foundation of geographic routing. These databases map IP address ranges to physical locations, allowing CDN infrastructure to determine where a user is located based on their IP address. The two most widely used databases are MaxMind GeoIP2 (commercial) and MaxMind GeoLite2 (free), though alternatives from IP2Location, DB-IP, and ipinfo.io also exist.

A GeoIP lookup takes an IP address and returns geographic attributes including country, region or state, city, latitude, longitude, time zone, and ISP name. The CDN's DNS infrastructure or load balancer uses these attributes to select the nearest or most appropriate edge server.

GeoIP accuracy varies substantially by granularity level:

The accuracy drops significantly for certain connection types. Mobile connections are particularly challenging because carrier IP addresses may be registered to the carrier's headquarters rather than the cell tower serving the user. A mobile user in Miami might have an IP address geolocated to the carrier's network operations center in Dallas. Satellite internet connections (Starlink, HughesNet) present similar challenges because the ground station location determines the IP geolocation, not the user's dish location.

CDN operators mitigate GeoIP inaccuracies by routing at the regional level (continent or large region) rather than the city level. A routing decision between "US East" and "US West" requires only state-level accuracy, which is reliable. A routing decision between "New York PoP" and "Philadelphia PoP" requires city-level accuracy, which is not. Using broad geographic buckets absorbs GeoIP errors without significantly impacting latency, since PoPs within the same region typically offer similar performance.

What Is EDNS Client Subnet and Why Does It Matter?

EDNS Client Subnet (ECS), defined in RFC 7871, addresses a fundamental limitation of DNS-based geo-routing. When a user queries a CDN hostname, the request typically passes through a recursive DNS resolver (such as Google Public DNS at 8.8.8.8 or Cloudflare DNS at 1.1.1.1). The CDN's authoritative DNS server sees the resolver's IP address, not the user's. If a user in Tokyo uses a Google DNS resolver located in California, the CDN may route them to a US edge server instead of a Tokyo PoP.

ECS solves this by allowing the recursive resolver to include a truncated portion of the client's IP address in the DNS query. The CDN's authoritative server can then use this client subnet to make a more accurate geographic routing decision. The truncation (typically /24 for IPv4 and /56 for IPv6) preserves user privacy while providing enough geographic information for effective routing.

Not all DNS resolvers support ECS. Google Public DNS and OpenDNS support it, but Cloudflare DNS (1.1.1.1) does not, citing privacy concerns. When a resolver does not support ECS, the CDN falls back to resolver-based geolocation. CDN operators must design their routing logic to produce reasonable results both with and without ECS data.

From a CDN perspective, ECS support requires modifications to the DNS routing infrastructure. The authoritative DNS server must parse the ECS option from incoming queries, use the client subnet for geographic lookup, and include appropriate scope information in the response so that resolvers cache the answer correctly. Incorrect scope handling can cause resolvers to serve cached responses to clients in the wrong location.

How Does GPS-Based Routing Work for Mobile Applications?

GPS-based routing uses the device's actual geographic coordinates rather than its IP address to determine location. This approach is available only for native mobile applications and web applications where the user has granted location permissions. The application includes GPS coordinates in request headers or query parameters, and the CDN uses these coordinates to route to the nearest edge server.

GPS-based routing provides the highest accuracy of any geo-routing method, typically within 10 meters of the user's actual position. This precision is unnecessary for most CDN routing decisions (selecting between PoPs that are hundreds of kilometers apart), but it enables use cases that IP-based routing cannot support:

• Hyper-local content delivery: Serving location-specific content (store inventories, local news, regional pricing) based on the user's exact position.
• Mobile edge computing: Routing to the nearest 5G MEC node where proximity is measured in single-digit milliseconds.
• VPN transparency: Accurately routing users who are connected through VPNs by using their actual device location rather than the VPN exit node IP.

The significant limitation is that GPS-based routing requires explicit user consent and only works in applications, not at the DNS or network level. It cannot be used for the initial CDN routing decision (which happens at DNS resolution time before any application code runs) and is therefore a supplementary method used alongside DNS-based or anycast routing.

What Is Geo-Fencing and How Do CDNs Implement It?

Geo-fencing uses geographic boundaries to control content access and delivery. Unlike routing optimization (which sends users to the nearest server), geo-fencing restricts which users can access content based on their location. CDN geo-fencing implementations serve three primary purposes.

Content licensing compliance: Media companies license content for specific territories. A streaming service may have rights to show a film in the US and Canada but not in Europe. Geo-fencing ensures that requests from European IP addresses receive a licensing restriction message rather than the content itself.

Sanctions and trade compliance: Companies must comply with trade sanctions that prohibit serving content or software to certain countries. CDN geo-fencing blocks all requests originating from sanctioned territories, typically returning a 403 Forbidden response.

Launch region control: When launching a product or feature in specific markets first, geo-fencing restricts access to approved regions. The CDN checks the user's geographic location before serving the content, returning either the content or a "not available in your region" page.

Geo-fencing is typically implemented at the edge server level using rules that evaluate the request's GeoIP data against an allow or deny list. Edge compute platforms (Cloudflare Workers, Lambda@Edge) provide the flexibility to implement complex geo-fencing logic, including different responses for different regions, language-based redirects, and time-zone-aware content release schedules.

How Does Compliance Routing Address Data Sovereignty Requirements?

Data sovereignty regulations such as GDPR (European Union), LGPD (Brazil), POPIA (South Africa), and PDPA (Thailand) impose restrictions on where personal data can be processed and stored. For CDNs, compliance routing ensures that content containing personal data is cached only in data centers within approved jurisdictions.

Standard CDN behavior replicates cached content across the entire network to maximize performance. A page cached in Frankfurt may also be cached in Tokyo, Sydney, and Sao Paulo. For content containing EU personal data, compliance routing restricts caching to EU data centers only. This means a user in the US requesting the content would be served from an EU edge server rather than a US one, accepting higher latency in exchange for data sovereignty compliance.

CDN providers implement compliance routing through region-restriction features:

• Cloudflare: Data Localization Suite restricts where data is inspected and stored.
• AWS CloudFront: Geographic restrictions and custom origin failover with region-specific origins.
• Akamai: Geographic-based access control and region-specific cache partitioning.
• Fastly: VCL-based geo-restriction and regional shield configuration.

Implementing compliance routing requires careful coordination between legal, engineering, and operations teams. The CDN configuration must align with the organization's data processing agreements and privacy policies. Misconfigurations can result in personal data being cached in non-compliant jurisdictions, potentially triggering regulatory penalties.

When Should You Choose Latency-Based Routing Over Geographic Proximity?

Geographic proximity routing assumes that the nearest server delivers the lowest latency. This assumption holds in most cases but fails when network topology diverges from physical geography. A user in a border city may have better network connectivity to a server in a neighboring country than to one in a distant city within their own country. Submarine cable routes, peering arrangements, and ISP transit paths all create scenarios where the fastest server is not the closest one.

Latency-based routing measures actual network round-trip times and routes users to the server with the lowest measured latency, regardless of geographic distance. This approach requires continuous measurement infrastructure: active probes between CDN PoPs, passive latency collection from real user traffic, or integration with performance monitoring systems.

The practical recommendation is to use geographic routing as the default with latency-based adjustments for known problematic regions. If latency monitoring reveals that users in a specific geography are being routed suboptimally, add an explicit routing override for that region. This provides the stability of geographic routing with the performance optimization of latency-based routing where it matters most.

What Are the Accuracy Limitations of Geo-Routing?

Every geo-routing method has accuracy limits that operators must understand and design around. Beyond the GeoIP accuracy challenges discussed earlier, several systematic issues affect geo-routing accuracy:

• VPN and proxy traffic: Users appear to originate from the VPN exit node's location. A user in Berlin using a US VPN will be routed to a US edge server. CDNs cannot reliably detect all VPN usage, though some maintain databases of known VPN IP ranges.
• Carrier-grade NAT: Mobile carriers and some ISPs share IP addresses among thousands of users across different geographic areas. The GeoIP database may locate the IP at the carrier's gateway rather than the user's location.
• IPv6 transition: IPv6 address allocation follows different patterns than IPv4, and GeoIP databases historically have lower accuracy for IPv6 ranges. This is improving as IPv6 adoption increases and databases mature.
• Stale databases: IP address allocations change as ISPs expand, merge, or redistribute blocks. A GeoIP database that is not updated regularly will produce increasingly inaccurate results. MaxMind updates their databases weekly; using monthly or quarterly updates introduces routing errors for recently reallocated IP ranges.

The practical impact of these limitations depends on the granularity of routing decisions. For continent-level and country-level routing, accuracy is sufficient for all production use cases. For city-level and sub-city routing, GeoIP inaccuracies become significant enough that alternative approaches, such as latency-based routing or application-layer traffic management, should supplement or replace pure geographic routing.