What Is Surrogate Control?
Surrogate control refers to instructions sent through the Surrogate-Control HTTP response header to supporting intermediary caches, such as CDN edge servers and reverse proxies.
Its main purpose is to let an origin server define a caching policy for those intermediaries separately from the policy used by browsers. For example, a CDN might retain a response as fresh for two hours while browsers receive a much shorter freshness lifetime.
How Surrogate Control Works
Set the Policy at the Origin
The origin includes Surrogate-Control in its response. A supporting CDN reads the header and uses the applicable directives when deciding how to handle its cached copy.
For an otherwise cacheable response, an illustrative configuration could be:
Cache-Control: public, max-age=120 Surrogate-Control: max-age=7200
This declares a 120-second freshness lifetime through Cache-Control and a 7,200-second lifetime for a surrogate that supports the second header.
Apply the CDN’s Header Rules
The CDN interprets the header according to its implementation and configuration. Cacheability decisions can also depend on response details, other directives, and custom rules. Check the documentation for your CDN provider for more information.
Surrogate-Control vs. Cache-Control
The Cache-Control Header applies to HTTP caching generally, including browser and shared caches. Some of its directives already distinguish between those audiences.
| Header or directive | Intended scope |
|---|---|
| Cache-Control: max-age | Freshness lifetime for caches generally, subject to other applicable directives |
| Cache-Control: s-maxage | Freshness lifetime specifically for shared caches |
| Surrogate-Control | Instructions for supporting surrogate caches |
| CDN-Cache-Control | Standardized targeted instructions for supporting CDN caches |
RFC 9213 defines CDN-Cache-Control and a framework for targeted cache policies. Supporting caches choose applicable targeted fields according to their priority rules.
Why Surrogate Control Matters
Consider a retailer publishing a promotional image that may need replacing during a campaign. Repeatedly requesting it from the origin would add unnecessary traffic, but a long browser freshness lifetime could delay users seeing a replacement.
Separate policies let the retailer give its CDN a longer freshness lifetime while keeping browser caching more conservative. When the image changes, the publishing workflow can purge the CDN copy.
Benefits and Challenges of Surrogate Control
Surrogate control provides a dedicated place to express intermediary caching policy. This can help teams reduce origin traffic while managing how quickly browsers revisit content.
However, different platforms may support different directives or apply additional caching rules. A configuration that works on one CDN may require changes elsewhere.
Long freshness lifetimes also require a deliberate update process. Teams need to know which cached variants a purge affects, including transformed image sizes or alternate formats.
Layered caching introduces an additional element: the current age of the response can influence how subsequent caches determine its freshness. Testing should therefore cover delivered responses, rather than only origin headers.
