CDN Request Lifecycle: From Browser to Edge to Origin and Back

Direct Answer: A CDN request lifecycle routes the browser via Anycast DNS to the nearest edge PoP, negotiates TCP/TLS, checks the edge cache, serves on HIT or fetches from origin on MISS, applies caching rules, and streams the response back with edge optimizations for fast, secure delivery.

Understanding the CDN request lifecycle is essential for debugging performance, configuring caching correctly, and reasoning about security. Every request follows a deterministic path: browser → recursive DNS → CDN authoritative DNS → Anycast edge → cache lookup → (optionally) origin → edge processing → client. Each hop has distinct failure modes and tuning knobs.

As a CDN Solutions Architect who has migrated media, SaaS, and e-commerce workloads to multi-PoP architectures, I have seen the same lifecycle reduce TTFB from 600ms to under 45ms globally when each stage is tuned. This guide walks through each stage with real headers, configs, and trade-offs.

1. DNS Resolution and Anycast Routing to the Nearest Edge

Everything starts before a single HTTP byte is sent. The browser needs an IP for www.example.com, which is typically a CNAME to the CDN, such as www.example.com.cdn.net. The operating system's stub resolver queries the recursive resolver, which walks the DNS hierarchy to the CDN's authoritative nameservers.

Modern CDNs do not return a single static IP. They use Anycast, where dozens or hundreds of PoPs advertise the same IP prefix via BGP. Your ISP's routers naturally forward packets to the topologically closest PoP. Inside the PoP, an L4 load balancer selects a healthy edge server using consistent hashing and least-connections.

How Anycast and GeoDNS Steer Requests

Anycast alone is powerful, but most providers layer latency-based DNS and EDNS Client Subnet (ECS) on top. ECS forwards a truncated /24 of the client IP to the authoritative DNS, allowing the CDN to return a PoP that is not just BGP-close but also latency-optimal and capacity-aware. If a PoP is saturated or draining for maintenance, DNS can steer new users elsewhere within the TTL window.

DNS TTLs matter for agility. A 30-60 second TTL on the edge CNAME lets you fail over quickly, while a longer TTL on the apex reduces lookup volume. For root domains, use ALIAS/ANAME records that resolve at the authoritative level to avoid CNAME-at-apex violations.

; dig www.example.com
www.example.com.  60  IN  CNAME  www.example.com.cdn.net.
www.example.com.cdn.net. 30 IN  A  151.101.1.1  ; Anycast - same IP announced from 300+ PoPs
www.example.com.cdn.net. 30 IN  A  151.101.129.1

# Check which PoP you hit
curl -sI https://www.example.com/ | grep -i "x-cache\|server\|pop"

For a deeper look at how DNS interacts with TLS certificates and edge hostnames, see our guide to CDN SSL/TLS configuration, which covers ALIAS records, CNAME setup, and certificate validation flows.

2. TCP and TLS Handshake at the Edge

Once the client has the Anycast IP, it opens a TCP connection to the edge. With modern stacks this is TCP with ECN and window scaling, followed immediately by TLS 1.3. The edge terminates TLS: it presents a certificate for your domain, negotiates cipher suites, and decrypts the request so it can apply HTTP logic and caching.

TLS termination at the edge is intentional. Without decryption, the CDN cannot read Cache-Control, route by path, or inject optimizations. The edge maintains a session cache and supports 0-RTT for resumed connections, cutting handshake time from 2-RTT to 1-RTT on repeat visits.

TLS Termination and Certificate Management

Most teams automate certificates via ACME (Let's Encrypt) or upload custom certs. The edge handles OCSP stapling, SCTs, and cipher preference. Between edge and origin, you should enforce TLS as well — ideally TLS 1.2+ with a valid origin certificate, or mutual TLS if you want to ensure only your CDN can fetch from origin. Learn more about protocol negotiation in CDN HTTP/2, HTTP/3 and QUIC.

# Nginx as origin - enforce CDN-only TLS
server {
  listen 443 ssl http2;
  server_name origin.example.com;
  ssl_certificate /etc/ssl/certs/origin.crt;
  ssl_certificate_key /etc/ssl/private/origin.key;
  ssl_protocols TLSv1.2 TLSv1.3;
  ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256;
  ssl_verify_client on; # require mTLS from CDN
  ssl_client_certificate /etc/ssl/cdn-ca.crt;
  add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;
}

Handshake performance is dominated by round trips. An edge 15ms from the user completes TLS 1.3 in ~30ms, while a direct origin 120ms away takes ~240ms. That delta alone justifies edge termination even before caching.

3. HTTP Request Processing and Edge Logic

With a decrypted HTTP request in hand, the edge runs a pipeline of logic before it ever checks the cache. This pipeline is where you get the most leverage for performance and security.

First, the edge normalizes the request: lowercases the host, removes dot segments, sorts query parameters if configured, and collapses duplicate slashes. Normalization ensures /Product?id=1&utm_source=x and /product?utm_source=x&id=1 can map to the same cache key if you choose to ignore marketing params.

Next, it evaluates firewall and bot rules, rate limits, and geo or token authentication. Blocking at the edge saves origin capacity and avoids cache pollution from abusive traffic. For DDoS patterns that would otherwise exhaust origin, edge filtering is critical — see CDN DDoS protection for edge rate-limiting and challenge strategies.

Finally, the edge can execute lightweight compute. Edge Workers or VCL can rewrite headers, A/B test, or personalize without an origin round trip. If you need heavier computation, edge computing lets you run JavaScript/WASM at the PoP with sub-millisecond overhead.

// Cloudflare Worker - normalize cache key at edge
export default {
  async fetch(request, env, ctx) {
    let url = new URL(request.url);
    // strip marketing params from cache key
    ['utm_source','utm_medium','gclid'].forEach(p => url.searchParams.delete(p));
    let newReq = new Request(url, request);
    return fetch(newReq, { cf: { cacheKey: url.toString() } });
  }
}

Edge logic also decides whether a request is cacheable at all. POST, PUT, or requests with Authorization or Cookie headers are typically classified as PASS, bypassing the cache entirely.

4. Cache Lookup: HIT, MISS, PASS, and STALE

The cache lookup is the heart of the lifecycle. The edge computes a cache key — usually host + path + query (filtered) + Vary headers — and checks its local store, which is tiered: in-memory (fastest), local SSD, and sometimes a regional shield.

A HIT means the object is fresh: its age is less than max-age or s-maxage, and no revalidation is needed. The edge can serve immediately, adding headers like X-Cache: HIT and Age: 42. A MISS means no usable copy exists, so the edge must fetch from origin. PASS means the response is intentionally uncacheable, and STALE means the object is expired but may be served while revalidation happens in the background.

Cache keys deserve careful design. Including the full query string by default can fragment your cache and lower hit ratio. Best practice is to include only parameters that change content, and to normalize case and order. Similarly, Vary: Accept-Encoding, Accept-Language multiplies variants — use it only when you truly serve different bytes per header.

Hit ratio is your north star. A well-tuned static asset workload should see 95%+ HIT, while personalized HTML may sit at 60-80% with proper micro-caching. Monitor hit ratio per content type, not just globally.

5. Origin Fetch on Cache MISS

When the edge cannot serve from cache, it must fetch from origin. To avoid thundering herds — where 1,000 simultaneous MISSes for the same viral image hammer your origin — edges use request collapsing (also called coalescing). Only the first MISS goes to origin; concurrent requests wait for that single origin response.

Many CDNs add a shield or origin shield layer: a designated regional PoP that sits in front of your origin. Instead of 50 global edges each fetching from origin, they fetch from the shield, which fetches once from origin. This reduces origin load by an order of magnitude and improves cache efficiency.

Shield, Collapsing, and Conditional Revalidation

If the edge has a stale copy, it can send a conditional request using If-None-Match (ETag) or If-Modified-Since. If the origin replies 304 Not Modified, the edge refreshes the TTL without re-downloading the body, saving bandwidth and time. This is especially valuable for large images or video segments.

# Varnish VCL - request collapsing + conditional revalidation
sub vcl_hit {
  if (obj.ttl >= 0s) { return (deliver); }
  if (obj.ttl + obj.grace > 0s) {
    // serve stale while background fetch
    return (deliver);
  }
}
sub vcl_backend_response {
  set beresp.ttl = 1h;
  set beresp.grace = 24h; # serve stale on origin failure
  if (beresp.http.ETag) {
    set beresp.http.Cache-Control = "public, max-age=3600, stale-while-revalidate=600";
  }
}

Origin fetches should reuse keep-alive connections and TLS sessions. Configure your origin to support HTTP/2 or HTTP/3 to the shield, enable TCP BBR, and ensure your origin can handle the CDN's concurrency. A misconfigured origin that closes connections aggressively will inflate MISS latency.

For invalidation strategy after origin updates, see CDN cache invalidation — purging by surrogate key or versioned URLs is far more reliable than waiting for TTL expiry.

6. Response Processing and Caching Rules

Once the origin response arrives (or a HIT is found), the edge applies response processing before delivery. It strips hop-by-hop headers, normalizes Cache-Control, and decides what to store.

The hierarchy is: CDN-Cache-Control or Surrogate-Control overrides Cache-Control: s-maxage, which overrides max-age. For example, you might want browsers to cache for 60 seconds but edges for 1 hour:

# Origin response headers - different TTLs for browser vs edge
Cache-Control: public, max-age=60, stale-while-revalidate=30
CDN-Cache-Control: public, max-age=3600, stale-while-revalidate=600, stale-if-error=86400
Surrogate-Key: product-123 product-list category-shoes
Vary: Accept-Encoding
ETag: "a3f9c1e2b4"

Surrogate keys (also called cache tags) let you purge related objects atomically. Purging product-123 invalidates the product page, API response, and image variants in one call, without purging the entire site.

The edge also compresses on the fly. If the client sent Accept-Encoding: gzip, br, the edge serves Brotli if pre-compressed, otherwise gzip, and caches both variants separately. Image optimization, minification, and Vary handling happen here too. Be cautious with Set-Cookie — any response with Set-Cookie should be marked private or no-store unless you explicitly want to cache per-user content (you usually do not).

# CloudFront / Fastly style cache behavior
{
  "pathPattern": "/static/*",
  "viewerProtocolPolicy": "redirect-to-https",
  "cachePolicy": {
    "minTTL": 86400,
    "maxTTL": 31536000,
    "defaultTTL": 86400,
    "compress": true,
    "queryStringWhitelist": ["v", "w"]
  }
}

Negative caching is often overlooked. Caching 404s for 10-30 seconds prevents origin floods when a bad link goes viral, while caching 500s for 1-5 seconds avoids retry storms. Configure these explicitly rather than relying on defaults.

7. Delivery Back to the Browser and Client Reuse

The final leg streams the response back over the already-established TLS connection. The edge sets Age, X-Cache, and often Server-Timing headers so you can debug the path:

HTTP/2 200
date: Fri, 05 Sep 2026 14:22:10 GMT
content-type: text/html; charset=utf-8
cache-control: public, max-age=60
cdn-cache-control: public, max-age=3600
age: 18
x-cache: HIT
server-timing: cdn-cache; desc=HIT, edge; dur=4, origin; dur=0
strict-transport-security: max-age=63072000; includeSubDomains
content-encoding: br

Delivery is not just bytes; it is also protocol optimization. The edge speaks HTTP/2 or HTTP/3 (QUIC) to the browser even if the origin only speaks HTTP/1.1, gaining multiplexing, header compression, and 0-RTT resumption. QUIC's migration support also helps mobile users who switch from Wi-Fi to cellular mid-request without re-establishing the connection.

On the client, the browser caches according to max-age. A subsequent navigation within 60 seconds will be served from the browser's memory cache with no network request at all — the fastest HIT is the one that never leaves the device. For assets that change infrequently, use immutable versioned URLs with Cache-Control: public, max-age=31536000, immutable to allow year-long browser caching.

8. Observability Across the Lifecycle

You cannot tune what you cannot measure. Instrument each stage: DNS lookup time, TCP connect, TLS handshake, TTFB, cache status, and origin latency. Most CDNs expose these via Server-Timing, real-time logs, and analytics APIs.

Key metrics to alert on are edge hit ratio, origin 5xx rate, p95 TTFB by PoP, and shield hit ratio. A sudden drop in hit ratio often indicates a cache-key change, an accidental Vary: *, or a purge gone wrong. A spike in MISS latency points to origin or shield saturation.

Centralize logs with request IDs that propagate from edge to origin. Add a unique X-Request-ID at the edge and echo it from origin so you can correlate a slow MISS with origin traces. Our guide to CDN monitoring and observability details log pipelines, sampling, and SLOs for each lifecycle stage.

# Correlate edge and origin with request ID
curl -i https://www.example.com/api/products -H "X-Request-ID: debug-123"

# Tail edge logs (Fastly example)
fastly logs tail --service-id=abc123 --format "%h %t \"%r\" %>s %b %{X-Cache}o %{Server-Timing}o"

Synthetic monitoring from multiple geographies complements real-user monitoring. Test both HIT and MISS paths: a HIT test validates edge health, while a MISS test with Cache-Control: no-cache or a unique query string validates origin and shield connectivity.

9. Putting It All Together: End-to-End Timeline

A typical HIT for a cached image 20ms from the user looks like this: DNS 8ms (cached recursive), TCP 20ms, TLS 1.3 20ms (1-RTT), cache lookup 2ms, delivery 15ms — total ~65ms TTFB. A MISS for uncached HTML adds shield 25ms plus origin 80ms plus cache write 5ms, totaling ~175ms.

Optimizations compound. Enabling 0-RTT saves 20ms on repeat visits, Brotli saves 15-25% bytes, shield saves origin round trips, and stale-while-revalidate hides revalidation latency entirely. The lifecycle is not just a flow chart; it is a set of levers you can pull to trade freshness, cost, and speed.

Start by auditing your current headers with curl -svo /dev/null https://yourdomain.com/ and mapping each response to the table above. Then fix cache keys, add surrogate keys, and set explicit browser vs edge TTLs. Each improvement moves more requests from the MISS path to the HIT path, which is where CDNs deliver their value.