CDN Routing: How a Request Finds the Nearest Edge

A CDN decides which of its edge locations answers your visitor using one of three mechanisms: DNS-based routing, BGP anycast, or a global load balancer combining both with health and capacity data.

Knowing which one your provider uses explains most of the odd behaviour people report: why a visitor in one country hits a point of presence in another, why cache hit ratios differ between regions, and why a traffic spike sometimes lands entirely on one location. It also tells you which knobs are yours and which are the network’s.

Table of contents

• DNS-based routing
• Anycast routing
• Global server load balancing
• What happens after the routing decision
• Diagnosing routing in practice
• What is actually worth your time
• How this fits the rest of the stack
• FAQ

DNS-based routing

The oldest approach. When a browser resolves your hostname, the CDN’s authoritative DNS server looks at where the query came from and returns the IP address of a nearby edge cluster. Different users asking for the same name get different answers.

The weakness is in that phrase, where the query came from. The authoritative server sees the resolver’s address, not the user’s. If your visitor in Portugal uses a public resolver whose nearest node is in Spain, the CDN sees Spain.

Extension Client Subnet fixes most of this. It lets the resolver pass along a truncated prefix of the user’s address, so the authoritative server can make a decision based on the actual client network rather than the resolver’s. Most large public resolvers support it, and support is not universal.

The other constraint is TTL. Because routing happens at resolution time, the routing decision is cached for as long as the record’s TTL says. Short TTLs give faster failover and more DNS traffic. This is the one lever in DNS routing that is genuinely yours.

Anycast routing

Anycast takes a different approach: announce the same IP address from every location at once, using BGP, and let internet routing decide. Every point of presence advertises the same prefix, and each router along the way forwards the packet toward whichever announcement looks closest by BGP metrics.

The consequences are worth stating plainly:

• Failover is automatic and fast. If a location stops announcing the prefix, traffic reroutes without any DNS change and without waiting for a TTL to expire.
• It is inherently DDoS resilient, because an attack is distributed across every location that announces the prefix rather than concentrated on one.
• Nearest is measured in BGP terms, not kilometres. The topologically closest location can be geographically surprising, which is why a visitor sometimes lands two countries away and the routing is still correct.
• You cannot steer it from your side. Announcements and peering are the provider’s business.

Anycast is why modern CDNs feel like a single address rather than a directory of regional endpoints, and why their DNS records are stable and boring.

Global server load balancing

GSLB is the combination approach: use DNS or anycast to get a request into the right region, then make a more informed choice using real-time inputs.

Those inputs typically include latency measurements between networks and locations, current load and capacity at each location, health check results, and policy rules you have configured such as keeping certain traffic in certain jurisdictions.

This is what gets used at large scale, because pure proximity is not the goal. The goal is the fastest response, and the nearest location is not the fastest one if it is saturated, degraded, or missing the object in cache.

It is also where any routing control you have will live, if you have any. Traffic steering rules, regional pinning for data residency, and origin selection for dynamic content are GSLB features.

What happens after the routing decision

Routing gets the request to an edge. What happens next determines whether any of it helped.

The edge checks its cache. On a hit, it responds directly and the origin never hears about the request. On a miss, it fetches from your origin, stores the response according to your cache headers, and serves it.

That last clause is the one people neglect. Routing is the provider’s job and caching is yours, and a perfectly routed request that misses the cache every time has bought you a slightly shorter path to the same slow origin.

Cache-Control: public, max-age=31536000, immutable   # fingerprinted assets
Cache-Control: public, max-age=0, s-maxage=300       # HTML, short edge cache
Cache-Control: private, no-store                     # anything user-specific

The distinction between max-age and s-maxage is the useful one: the first instructs browsers, the second instructs shared caches like the CDN. Setting a long edge cache with a short browser cache gives you fast delivery and the ability to purge.

Watch the cache status header your provider sends. A HIT ratio below about 80 percent on static assets means the configuration is wrong, not the network.

Diagnosing routing in practice

Three commands answer most questions.

dig +short yoursite.com
curl -sI https://yoursite.com | grep -iE 'cf-ray|x-cache|age|server'
curl -o /dev/null -s -w 'dns %{time_namelookup}  connect %{time_connect}  ttfb %{time_starttransfer}\n' https://yoursite.com

If dig returns the same address from everywhere in the world, you are on anycast. If it returns different addresses from different locations, it is DNS routing.

The response headers usually name the point of presence that served the request, often as an airport code, along with a cache status. That pair tells you both where the request landed and whether the cache did anything useful.

Common findings and their causes:

• Users routed to a distant location. Usually a resolver without ECS support, or an anycast announcement that is topologically closest despite the geography. The former you can influence, the latter you cannot.
• Good hit ratio in one region, poor in another. Each location has its own cache, so low-traffic regions cold-start more often. This is normal and self-correcting with volume.
• High time to first byte with a cache hit. The problem is not routing, it is the edge waiting on something, usually a revalidation request to a slow origin.
• Everything routes to one location during a spike. Either a single origin is the bottleneck or a steering rule is pinning traffic.

What is actually worth your time

Routing mechanics are interesting and mostly not adjustable. The things that change your numbers are almost all on your side of the line.

1. Set correct cache headers, with long lifetimes on fingerprinted assets and a short shared cache on HTML.
2. Fingerprint your assets so you can cache them forever and change the filename instead of purging.
3. Keep the origin fast, because every cache miss and every revalidation pays origin latency in full.
4. Set TTLs deliberately if you are on DNS routing, shorter for faster failover.
5. Measure the cache hit ratio per region rather than in aggregate, because an average hides the region that is broken.

A CDN in front of a slow origin with no cache headers is an expensive proxy. The network was never the hard part.

For static sites on RunxBuild, assets are served from the edge with 120GB of bandwidth included and ten cents a gigabyte after, and cache headers are configurable per path, which is where this work actually happens.

How this fits the rest of the stack

Content delivery costs are one of the easier things to underestimate, because bandwidth is invisible until it is a line on an invoice and cache misses turn into origin compute you did not plan for. The RunxBuild hosting calculator puts bandwidth next to the service, the database and the storage as separate figures, which makes it much easier to see whether a caching problem is about to become a billing one.

Useful related references:

• Cloud Edge: Edge Computing, CDN, and 5G MEC
• VPC Peering: Connection, Routing, and When to Use Transit Gateway
• CDN Content Delivery: What It Actually Does for Your Bill and Your Latency
• Services on RunxBuild

FAQ

What is CDN routing?

It is the process of deciding which edge location answers a given request. Providers do this with DNS-based routing, BGP anycast, or a global load balancer that combines both with health, capacity and latency data.

What is the difference between anycast and DNS-based routing?

DNS routing returns a different IP address depending on where the query appears to come from, so the decision is made at resolution time and cached for the record TTL. Anycast announces one address from every location and lets BGP decide per packet, which fails over instantly without waiting for DNS.

Why are my users routed to an edge server in another country?

Either the resolver they use does not pass client subnet information, so the CDN sees the resolver’s location rather than theirs, or the routing is anycast and the topologically nearest location is not the geographically nearest one. The second case is usually still the fastest path.

Can I control which edge location serves my users?

Rarely, and not directly. Anycast routing is decided by internet routing, not by you. If your provider offers global load balancing, you may get traffic steering rules or regional pinning for data residency, but proximity itself is not a setting.

Does a CDN make a slow website fast?

Only the parts it can cache. A CDN shortens the network path and serves cached objects from nearby, but every cache miss still pays full origin latency. If cache headers are missing or the origin is slow, a CDN is an expensive proxy rather than a speed-up.