Somebody puts a CDN in front of the site on a Friday. The homepage gets faster, the bill goes down, everyone is pleased. On Monday a customer emails to say they logged in and saw someone else’s name in the header.<\/p>\n\n\n\n
That is the failure mode worth taking seriously. Not slowness, not downtime \u2014 the CDN cached a page that was personalised for one user and served it to everybody else. And you will not notice, because your browser holds a session and looks fine. The people seeing the broken version are the ones who never contact you.<\/p>\n\n\n\n
Getting CDN setup right for a dynamic site is not about finding the right toggle in a dashboard. It is about deciding, per route, what is public and what is personal, and then making the origin say so clearly enough that no edge node has to guess.<\/p>\n\n\n\n
Every URL on your site falls into one of three buckets. Write the list out \u2014 actually write it, this takes ten minutes and prevents the incident above.<\/p>\n\n\n\n
The middle bucket is the whole game. If you cache only the first bucket you have built an asset CDN and left the expensive work untouched. If you accidentally cache the third, you have a data leak.<\/p>\n\n\n\n
The single most useful thing to understand is the difference between The other key pair is Set caching headers at the origin, per route, and let the CDN follow them. Configuring cache rules only in the CDN dashboard means the policy lives somewhere your application code cannot see and your staging environment does not have.<\/p>\n<\/blockquote>\n\n\n\n Now the one to avoid:<\/p>\n\n\n\n If you need device-specific responses, most CDNs expose a normalised device-type value with two or three possible values. Use that rather than the raw header.<\/p>\n\n\n\n Two rules, and between them they prevent most CDN incidents.<\/p>\n\n\n\n If a request arrives carrying your session cookie, it should go to origin uncached. Most CDNs let you express this as a cache rule; in nginx, if you are running your own edge, it is a variable:<\/p>\n\n\n\n You need both<\/em> directives. That Analytics and consent tools set cookies on every visitor. If your CDN treats any cookie as a bypass signal, your anonymous traffic stops being cacheable the moment you add a tag manager. Configure the CDN to ignore everything except the specific cookies that matter, and be explicit about which those are.<\/p>\n\n\n\n By default many CDNs include the full query string in the cache key. Then a marketing campaign starts appending Decide deliberately which parameters affect the response:<\/p>\n\n\n\n An allowlist is safer than a blocklist here. New tracking parameters appear constantly; the set of parameters your application actually reads changes rarely.<\/p>\n\n\n\n The usual objection to caching public dynamic pages is that content changes. Two mechanisms solve this, and together they let you cache aggressively without serving stale content for long.<\/p>\n\n\n\n Read that as three separate promises. Fresh for sixty seconds. For the following ten minutes, serve the stale copy immediately while fetching a fresh one in the background \u2014 so nobody waits. And if the origin is throwing errors, keep serving the stale copy for a day rather than showing a 502.<\/p>\n\n\n\n That last directive turns your CDN into a partial outage shield. It is one of the highest-value headers on this page and it costs nothing.<\/p>\n\n\n\n Time-based expiry is a blunt instrument. If your application knows when a product price changed, tell the CDN immediately rather than waiting for a TTL.<\/p>\n\n\n\n Tag-based purging is the version worth building toward \u2014 tag responses by the entities they contain, then purge by tag when an entity changes:<\/p>\n\n\n\n Update product 1234 and you purge one tag, invalidating the product page, every category listing it appears on, and the homepage if it is featured \u2014 without knowing any of those URLs in advance. Header name and support vary by provider, so check what yours calls it.<\/p>\n\n\n\n Test with curl, not a browser. Your browser has cookies, a warm local cache and an opinion; curl tells you the truth.<\/p>\n\n\n\n Now the test that matters most. Request an authenticated page with a real session cookie and confirm it never returns a cache hit:<\/p>\n\n\n\n You want The leak test, which is the one people skip: fetch a personalised page with a session, then fetch the same URL with no cookies at all and confirm you get the anonymous version.<\/p>\n\n\n\n If the second command finds personalised content, the CDN cached a private response. That is the Monday-morning email, and you have just caught it before your customers did.<\/p>\n\n\n\n That sends a real request to a specific edge node with the correct hostname and TLS SNI, without changing DNS. It is how you find out whether the whole thing works before any user does.<\/p>\n\n\n\n Your logs fill with edge node addresses, rate limiting starts throttling everyone at once, and geolocation breaks. The real address arrives in a forwarded header, and your origin has to be configured to trust it \u2014 but only from the CDN’s address ranges. Trusting The CDN talks to your origin over HTTP, the origin sees a non-HTTPS request and redirects to HTTPS, which comes back through the CDN, forever. Either terminate TLS at the origin too, or have the origin trust Shouldn’t happen by default, but a badly written cache rule can do it, and the result is one user’s form submission response served to the next person. Only cache Websocket upgrades and server-sent events need to pass through untouched. Buffering breaks streaming responses silently \u2014 the connection works, the data just arrives in one lump at the end, which looks like an application bug rather than a proxy setting.<\/p>\n\n\n\n If a public page returns Yes, and that is where most of the benefit is. Dynamic does not mean personalised. A blog post rendered from a database is identical for every anonymous visitor and can be cached at the edge for minutes. Only genuinely per-user content must bypass.<\/p>\n\n\n\n Because the consent tool sets a cookie on every visitor and your CDN treats any cookie as a bypass signal, or you are varying on Request the page with a real session cookie and confirm the cache status shows a bypass or miss, never a hit. Then request the same URL with no cookies and confirm the personalised content is absent. Do this after every cache rule change.<\/p>\n\n\n\n Public read-only endpoints, yes \u2014 with short TTLs and a cache key that includes whatever parameters affect the response. Anything requiring an Authorization header should be treated as private by default.<\/p>\n\n\n\n Yes. The CDN protects you from repeat requests for the same URL; it does nothing for the first request, for uncacheable routes, or during a purge. Origin-level caching handles those.<\/p>\n\n\n\n A CDN in front of a dynamic site is a classification problem wearing a performance costume. Sort your routes into public, private and static; express that at the origin with Then test the way an anonymous visitor arrives, not the way you browse your own site. Two curl commands \u2014 one with a session, one without \u2014 catch the failure that matters, and they take about ten seconds. Run them every time you change a cache rule and the Monday email never arrives.<\/p>\n\n\n\n I work with teams on edge caching for dynamic sites \u2014 route classification, cache headers that survive a redesign, purge-on-publish wired into the application, and the monitoring that tells you when hit ratio quietly drops.<\/p>\n\n\n\n If you would rather have this done carefully the first time, you can hire me on Upwork.<\/p>\n\n\n\nprivate<\/code> and no-store<\/code>, because people use them interchangeably and they mean very different things.<\/p>\n\n\n\n# Static assets with a content hash in the filename\nCache-Control: public, max-age=31536000, immutable\n\n# Public dynamic: edge caches it, browser revalidates\nCache-Control: public, s-maxage=300, max-age=0, must-revalidate\n\n# Personalised: browser may cache, shared caches must not\nCache-Control: private, no-store\n\n# Genuinely sensitive: nobody stores this anywhere\nCache-Control: no-store<\/code><\/pre>\n\n\n\nprivate<\/code> means “a browser cache may keep this, a shared cache may not”. no-store<\/code> means “do not write this to disk anywhere”. For an authenticated dashboard you want both. For a bank statement you want no-store<\/code> alone.<\/p>\n\n\n\ns-maxage<\/code> versus max-age<\/code>. s-maxage<\/code> applies only to shared caches \u2014 the CDN \u2014 and overrides max-age<\/code> there. That lets you cache a product page at the edge for five minutes while telling browsers to revalidate every time, so a price change propagates in five minutes rather than living in someone’s browser for an hour.<\/p>\n\n\n\n\n
Vary, and how it quietly ruins your hit rate<\/h2>\n\n\n\n
Vary<\/code> tells caches that the response depends on a request header, so a separate copy is stored per distinct value. Used precisely it is essential. Used carelessly it destroys your cache.<\/p>\n\n\n\n# Fine. A handful of encodings, a handful of variants.\nVary: Accept-Encoding\n\n# Also fine if you genuinely serve different content per language\nVary: Accept-Encoding, Accept-Language<\/code><\/pre>\n\n\n\n# Effectively disables caching. Every browser build is a distinct\n# User-Agent string, so every visitor gets their own cache entry.\nVary: User-Agent<\/code><\/pre>\n\n\n\nVary: Cookie<\/code> deserves its own warning. It looks like a safe way to separate logged-in from anonymous traffic, and it is not \u2014 every visitor carries slightly different cookies from analytics and consent tools, so you get a near-unique cache key per person. The correct approach is to make the presence of a session cookie bypass the cache entirely, rather than varying on it.<\/p>\n\n\n\n
\n\n\n\nCookies are where sites actually break<\/h2>\n\n\n\n
Rule one: a session cookie means bypass<\/h3>\n\n\n\n
map $http_cookie $bypass_cache {\n default 0;\n \"~*wordpress_logged_in\" 1;\n \"~*woocommerce_items\" 1;\n \"~*comment_author\" 1;\n \"~*PHPSESSID\" 1;\n}\n\nlocation \/ {\n proxy_cache edge_cache;\n proxy_cache_bypass $bypass_cache; # do not serve from cache\n proxy_no_cache $bypass_cache; # do not write to cache\n proxy_cache_valid 200 301 302 5m;\n proxy_cache_use_stale error timeout updating http_500 http_502 http_503 http_504;\n proxy_cache_lock on;\n\n add_header X-Cache-Status $upstream_cache_status always;\n proxy_pass http:\/\/origin;\n}<\/code><\/pre>\n\n\n\nproxy_cache_bypass<\/code> stops a logged-in user being served a cached anonymous page. proxy_no_cache<\/code> stops their personalised response being written into the cache for everyone else. Setting only the first is a common and dangerous mistake \u2014 the read path is protected while the write path is wide open.<\/p>\n\n\n\nX-Cache-Status<\/code> header is not decoration. It is how you verify any of this actually works.<\/p>\n\n\n\nRule two: strip cookies you do not need<\/h3>\n\n\n\n
Query strings, and the cache-key explosion<\/h2>\n\n\n\n
utm_source<\/code>, utm_medium<\/code>, fbclid<\/code> and friends, and one page becomes thousands of cache entries that each miss exactly once.<\/p>\n\n\n\n\n
?page=2<\/code>, ?sort=price<\/code>, ?category=boots<\/code>.<\/li>\n\n?a=1&b=2<\/code> and ?b=2&a=1<\/code> are one entry rather than two.<\/li>\n<\/ul>\n\n\n\n
\n\n\n\nKeeping dynamic pages cached without going stale<\/h2>\n\n\n\n
Stale-while-revalidate<\/h3>\n\n\n\n
Cache-Control: public, s-maxage=60, stale-while-revalidate=600, stale-if-error=86400<\/code><\/pre>\n\n\n\nPurge on change<\/h3>\n\n\n\n
# Origin response for a product page\nCache-Tag: product-1234, category-boots, layout-main<\/code><\/pre>\n\n\n\nVerifying it before you point DNS<\/h2>\n\n\n\n
# What headers is the origin actually sending?\ncurl -sI https:\/\/example.com\/products\/boots | grep -i 'cache-control|vary|set-cookie'\n\n# Twice in a row: second request should show a HIT\ncurl -sI https:\/\/example.com\/products\/boots | grep -i 'x-cache|age'\ncurl -sI https:\/\/example.com\/products\/boots | grep -i 'x-cache|age'<\/code><\/pre>\n\n\n\ncurl -sI https:\/\/example.com\/account \n -H \"Cookie: session=<a-real-session-value>\" \n | grep -i 'x-cache|cache-control'<\/code><\/pre>\n\n\n\nBYPASS<\/code> or MISS<\/code>, and Cache-Control: private<\/code>. If that ever shows HIT<\/code>, stop and fix it before going further.<\/p>\n\n\n\n# With a session\ncurl -s https:\/\/example.com\/account -H \"Cookie: session=<value>\" | grep -i 'welcome back'\n\n# Immediately after, with nothing. Should NOT show the personalised content.\ncurl -s https:\/\/example.com\/account | grep -i 'welcome back'<\/code><\/pre>\n\n\n\nTest the edge before DNS points at it<\/h3>\n\n\n\n
curl -sI https:\/\/example.com\/ --resolve example.com:443:<edge-ip><\/code><\/pre>\n\n\n\n
\n\n\n\nThings that break in ways nobody expects<\/h2>\n\n\n\n
Client IPs all become the CDN’s<\/h3>\n\n\n\n
X-Forwarded-For<\/code> from anywhere lets any visitor claim any IP they like, which turns a logging annoyance into an authentication bypass.<\/p>\n\n\n\nRedirect loops<\/h3>\n\n\n\n
X-Forwarded-Proto<\/code> when deciding whether to redirect.<\/p>\n\n\n\nPOST responses getting cached<\/h3>\n\n\n\n
GET<\/code> and HEAD<\/code>. Ever.<\/p>\n\n\n\nWebsockets and streaming<\/h3>\n\n\n\n
Set-Cookie on a cacheable response<\/h3>\n\n\n\n
Set-Cookie<\/code> and gets cached, every subsequent visitor receives that cookie \u2014 potentially somebody’s session identifier. Most CDNs refuse to cache responses carrying Set-Cookie<\/code>, but not all, and not always. Check your origin is not setting cookies on pages you intend to cache.<\/p>\n\n\n\nRolling it out without a bad week<\/h2>\n\n\n\n
\n
Common mistakes<\/h2>\n\n\n\n
\n
proxy_cache_bypass<\/code> without proxy_no_cache<\/code>, protecting reads but not writes.<\/li>\n\nVary: Cookie<\/code> or Vary: User-Agent<\/code>, which shatters the cache into near-unique entries.<\/li>\n\nprivate<\/code> where you needed no-store<\/code>, or the reverse.<\/li>\n\nBest practices<\/h2>\n\n\n\n
\n
s-maxage<\/code> for the edge and max-age<\/code> for browsers. They are different problems.<\/li>\n\nstale-if-error<\/code>. It is free outage insurance.<\/li>\n\nFrequently asked questions<\/h2>\n\n\n\n
Can a CDN cache dynamic pages at all?<\/h3>\n\n\n\n
What is the difference between private and no-store?<\/h3>\n\n\n\n
private<\/code> permits browser caching but forbids shared caches. no-store<\/code> forbids writing the response to any cache at all. Use both for authenticated pages; use no-store<\/code> alone for genuinely sensitive responses.<\/p>\n\n\n\nWhy did my hit ratio collapse after adding a cookie banner?<\/h3>\n\n\n\n
Cookie<\/code>. Configure the CDN to ignore all cookies except the specific ones that indicate a session.<\/p>\n\n\n\nHow do I verify private pages are not being cached?<\/h3>\n\n\n\n
Should I cache API responses?<\/h3>\n\n\n\n
Do I still need caching at the origin?<\/h3>\n\n\n\n
Wrapping up<\/h2>\n\n\n\n
Cache-Control<\/code>; make session cookies a hard bypass on both the read and write path; and keep tracking parameters out of the cache key.<\/p>\n\n\n\n
\n\n\n\nWant a CDN set up without the surprises?<\/h2>\n\n\n\n