What is a CDN (Content Delivery Network)?

02What to cache, and for how long

The right lifetime depends on how a URL changes, not on its file type. Two extensions do much of the work: immutable (RFC 8246) tells caches that a response will not change during its freshness lifetime, and stale-while-revalidate (RFC 5861) lets a cache keep serving a just-expired copy while it fetches a new one in the background. Status codes have defaults of their own: a 301 or 404 sent without cache headers may still be stored, as which HTTP status codes can be cached explains.

03What you actually get

• Lower latency: distance is physics, and a response from 30 km away beats one from 3,000 km
• Less origin load: cached responses never reach your server, so it can be smaller
• Traffic spikes absorbed: a viral page is served from the edge instead of melting your origin
• Lower bandwidth bills: you pay for the cache fill, not for every visitor, which also lowers the peaks a 95th percentile bill is calculated from
• Attack resilience: flood traffic hitting cached URLs is answered without your origin noticing

04The part that goes wrong: caching the wrong thing

The most damaging CDN misconfiguration is caching a personalised response and serving it to someone else. If a page containing one user's name, basket or session is stored at the edge, the next visitor may receive it. That is a data breach caused by a caching rule.

The safeguards are straightforward but must be deliberate. The HTTP caching standard, RFC 9111, already forbids a shared cache from reusing a response to a request that carried an Authorization header unless the response explicitly allows it, and common proxy caches skip responses that set cookies: nginx's documentation states that a response with Set-Cookie 'will not be cached'. Treat anything behind a login as uncacheable unless you have thought carefully about it, and mark it private or no-store so the outcome never rests on defaults.

05How to check whether a response came from cache

Most CDNs report what they did, though not always in the same header. The Age header (RFC 9111) gives the seconds since the response was fetched or revalidated at the origin, so a non-zero Age usually means a cached copy. Cache-Status (RFC 9211) is the standard form, with values such as hit or fwd=miss; many providers still use their own X-Cache header.

Request the same URL twice and compare. A second response that is still a miss points to a header that prevents caching, a cookie, or a cache key that differs on every request. The HTTP headers checker lists every response header and shows which CDN answered, without installing anything.

curl -sI https://example.com/assets/app.css | grep -iE '^(cache-control|age|cache-status|x-cache|vary|set-cookie):'

# A cached asset typically answers with something like:
cache-control: public, max-age=31536000, immutable
age: 5321
cache-status: ExampleCDN; hit

06Tiered caching and cache stampedes

A naive CDN has a problem when something popular expires: every location that gets a request at that moment goes to the origin at once, and a single expiry becomes a burst of simultaneous requests. This is a cache stampede.

Two mechanisms prevent it. Request coalescing means concurrent misses for the same URL at one location produce a single origin fetch, with the others waiting for its result. Tiered caching adds an intermediate layer, so edge locations fetch from a regional cache rather than all reaching your server independently.

If you run your own cache in front of an application, the same ideas take a few lines of nginx. The configuration below follows your origin's Cache-Control headers, lets one request per missing item through to the origin while others wait (for up to proxy_cache_lock_timeout, five seconds by default), and keeps serving the stale copy while it refreshes or when the origin fails.

# http {} context
proxy_cache_path /var/cache/nginx/app levels=1:2 keys_zone=app:10m
                 max_size=1g inactive=60m use_temp_path=off;

server {
    listen 80;
    server_name example.com;

    location / {
        proxy_pass http://127.0.0.1:8080;
        proxy_cache app;
        proxy_cache_lock on;
        proxy_cache_use_stale updating error timeout http_502 http_503 http_504;
        proxy_cache_background_update on;
        add_header X-Cache-Status $upstream_cache_status always;
    }
}

07Cache keys and cache-busting

A cache stores each response under a key. RFC 9111 defines the key as the request method and target URI, and nginx's default key combines the scheme, the upstream host and the full request URI, query string included. The Vary header adds request headers to the key: Vary: Accept-Encoding is harmless, while Vary: User-Agent or Vary: Cookie can split one page into thousands of copies and wreck your hit ratio.

The same mechanism is how floods get past a cache. Appending a random query string makes every request a new key, so every request is a miss that reaches your origin. It is a standard technique in HTTP floods, and the defences are the usual ones: ignore or normalise query parameters a route does not use, keep uncacheable routes behind rate limits and WAF rules, and make sure the origin can refuse work cheaply.

08Why CDNs and security belong together

A CDN and a web application firewall occupy the same position: both are a reverse proxy sitting between your visitors and your origin. Running them as one system rather than two means a request is terminated once, inspected, and served or forwarded in a single hop, instead of paying the cost of two proxies in sequence.

It also makes caching part of your defence. During an attack, requests for URLs already in cache are answered at the edge and never reach your origin. Attack traffic aimed at cacheable content is, from the origin's point of view, absorbed for free.

09Troubleshooting common CDN problems