CDN-Cache-Control proxy response

What it does

CDN-Cache-Control is a targeted Cache-Control — it carries the same directives but only applies to CDN caches, not browsers. This lets you set different caching strategies for your CDN and your users' browsers from the same response, without needing Cache-Control: s-maxage.

Cache-Control: public, max-age=60        ← browsers cache for 1 minute
CDN-Cache-Control: max-age=86400         ← CDN caches for 24 hours

Same response. Browser respects Cache-Control. CDN respects CDN-Cache-Control.

Syntax

Identical to Cache-Control — same directives, same values:

CDN-Cache-Control: max-age=86400
CDN-Cache-Control: no-store
CDN-Cache-Control: max-age=3600, stale-while-revalidate=86400
CDN-Cache-Control: no-cache

CDN-Cache-Control vs s-maxage

Before this header existed, Cache-Control: s-maxage was the way to set a separate TTL for shared caches (CDNs, proxies) vs browsers. They serve the same purpose but with key differences:

Use s-maxage when you want consistent behaviour across all shared caches. Use CDN-Cache-Control when you specifically want to target CDN behaviour and potentially leave non-CDN proxies to follow Cache-Control.

Vendor-specific precedence

CDNs that support CDN-Cache-Control treat it as higher priority than Cache-Control. The hierarchy typically is:

CDN-Cache-Control > Surrogate-Control (Fastly/Varnish) > Cache-Control: s-maxage > Cache-Control: max-age

Check your CDN's documentation — Cloudflare, Fastly, and AWS CloudFront all have slightly different precedence rules.

Practical patterns

Long CDN TTL, short browser TTL (most common):

Cache-Control: public, max-age=60
CDN-Cache-Control: max-age=86400

CDN holds it for a day, browsers revalidate every minute. You can purge the CDN on deploy; browsers naturally refresh frequently.

CDN caches, browsers don't:

Cache-Control: no-store
CDN-Cache-Control: max-age=3600

Sensitive personalised content: browsers never cache it, but the CDN can serve a shared version to multiple users.

Neither caches (override CDN default):

Cache-Control: no-store
CDN-Cache-Control: no-store

Explicitly prevent CDN caching even if the CDN would cache by default.

Aggressive CDN with stale-while-revalidate:

Cache-Control: public, max-age=60
CDN-Cache-Control: max-age=3600, stale-while-revalidate=86400

CDN serves fresh for 1 hour, then serves stale for up to a day while revalidating in background.

CDN support

• Cloudflare — supports CDN-Cache-Control natively
• Fastly — uses Surrogate-Control (their proprietary predecessor); CDN-Cache-Control support added
• AWS CloudFront — check current documentation; adoption growing post-RFC
• Akamai — uses Edge-Control (proprietary); RFC 9213 support in progress

Given the mixed adoption landscape in 2026, always test on your specific CDN. Using s-maxage alongside CDN-Cache-Control as a fallback is a safe approach during the transition period.

Real-world examples

API response: aggressive CDN caching, conservative browser:

HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: public, max-age=30
CDN-Cache-Control: max-age=3600
Vary: Accept-Encoding

HTML page: CDN caches, browsers always revalidate:

HTTP/1.1 200 OK
Content-Type: text/html
Cache-Control: no-cache
CDN-Cache-Control: max-age=86400

FAQ

Why not just use s-maxage?

s-maxage targets all shared caches — including corporate proxies and ISP caches that might sit between your CDN and the browser. If you only want to configure CDN behaviour specifically, CDN-Cache-Control is more surgical. In practice, s-maxage is still more widely understood and universally supported.

Can I use CDN-Cache-Control without Cache-Control?

Technically yes, but not recommended. CDNs that don't recognise CDN-Cache-Control will fall back to Cache-Control. If Cache-Control is absent, they may apply heuristic caching. Always set Cache-Control as the baseline.

Fun fact

CDN-Cache-Control (RFC 9213) is part of a wave of HTTP RFCs published in 2022 that attempted to clean up the messy ecosystem of CDN-specific cache headers. Before it, every CDN vendor invented their own solution: Fastly had Surrogate-Control, Akamai had Edge-Control, Cloudflare had their own rules. These proprietary headers worked fine within a single CDN but made multi-CDN setups and CDN migration nightmares — all your cache configuration was locked to one vendor's header format. RFC 9213 is the industry's attempt to standardise, though the decade-long head start of proprietary headers means adoption will take years.