Cloudflare Cache Response Rules: Fix Headers Safely at the Edge
By Greg Nowak. Updated 4 September 2026.
A public page should not require an application release simply because its response carries the wrong cache header. Cloudflare Cache Response Rules let you modify selected Cache-Control directives, manage cache tags, or remove specific headers after Cloudflare receives the origin response but before it makes the caching decision.
That can be a useful operational fix for public articles, documentation, product listings and campaign pages. It can reduce avoidable origin traffic while the application team works on a permanent correction. But it is also easy to hide an application problem—or cache private content—if the rule is too broad. Start with the cache decision, understand the header, and change the smallest possible surface.
Response Rules and Cache Rules solve different problems
Ordinary Cache Rules run against the incoming request. They determine whether a URL is eligible for caching and can control its edge TTL and cache key. Cache Response Rules run later, in Cloudflare’s http_response_cache_settings phase, when response properties are available.
A Response Rule can remove private, add an edge-specific TTL, strip Set-Cookie, or set no-store. It cannot make an ineligible request cacheable. If an HTML route returns DYNAMIC, first check whether a Cache Rule marks that route as eligible. If an eligible route returns BYPASS, investigate the origin response.
Response Rules take precedence when their settings conflict with Cache Rules. A matching Response Rule also defaults to Origin Cache Control behaviour, so review the complete rule stack rather than treating the new rule in isolation. Cloudflare Trace can show which rules match a particular URL.
Diagnose the live response before changing anything
Test representative URLs with a real GET request. Include important landing pages, low-traffic content, authenticated routes and at least one URL from each relevant template:
curl -sS -D - -o /dev/null https://www.example.com/important-pageCapture CF-Cache-Status, Age, Cache-Control, CDN-Cache-Control, Set-Cookie, Vary, ETag, Last-Modified and CF-Ray. Request the URL twice from the same client. A first MISS followed by HIT is normal; repeated misses need more investigation.
| Status | What Cloudflare decided | Best next check |
|---|---|---|
HIT |
A cached response was served. | Confirm its TTL, purge path and content correctness. |
MISS |
The response was eligible but absent from cache. | Repeat from the same location; then inspect cache-key variance, recent purges or eviction. |
BYPASS |
The request was eligible, but the response was not cacheable. | Inspect no-store, private, Set-Cookie, Vary: *, authorization and object size. |
DYNAMIC |
The request was ineligible before a cache lookup. | Review Cache Rules, method, Development Mode and default file-extension behaviour. |
UPDATING |
Stale content was served during background revalidation. | Usually expected when stale-while-revalidate is active. |
REVALIDATED |
The cached object was synchronously validated with the origin. | Check whether this is the intended freshness policy. |
CF-Cache-Status values.Since Cloudflare’s May 2026 cache-status change, responses it declines to store return BYPASS rather than an ambiguous repeated MISS. Do not assume every BYPASS comes from Cache-Control, however. A response can also be too large, contain Set-Cookie or Vary: *, or be affected by authorization and Origin Cache Control settings.
Choose routes that are genuinely safe to share
A good candidate is anonymous, repeatable and identical between visitors: a published article, public documentation page or unpersonalised campaign page. Poor candidates include carts, checkout, account pages, previews, dashboards and routes where cookies control identity, consent, pricing, currency or experiments.
Treat Set-Cookie as a warning, not clutter. Identify who creates the cookie and what breaks without it. Test logged-out and logged-in journeys separately. If the team cannot explain the cookie, do not strip it yet.
Validators also deserve care. Removing ETag can eliminate an efficient validation path. Cloudflare specifically warns that stripping Last-Modified with a Cache Response Rule disables Smart Edge Revalidation for that response. Header removal may cure one symptom while increasing later transfer or validation work.
Build a rule with a narrow blast radius
In the Cloudflare dashboard, open Cache > Cache Rules > Cache Response Rules. Give the rule a name that describes the route and purpose, then constrain it with several properties where practical:
- the exact hostname;
GETorHEADonly;- a specific path or template family;
- successful response statuses such as
200; - exclusions for previews, administration paths and session-bearing requests.
Change one concern per rule. If the origin’s browser policy is already correct but Cloudflare needs a different directive, use the Cloudflare only option so visitors continue receiving the original header. Remember that matching rules stack and the last matching rule wins for the same setting.
Roll out the change like a production release
- Baseline: save headers, cache statuses and expected page behaviour for a representative route set.
- Trace: confirm that the proposed rule matches only the intended URLs.
- Stage: use Cloudflare Version Management where it is available in your configuration; Cache Response Rules can be versioned and promoted between environments.
- Verify: make repeated live requests, confirm the correct content is returned, and test authenticated, consent and ecommerce journeys.
- Monitor: watch origin traffic, cache statuses and support signals by route. Record the rollback owner and previous configuration.
One TTL interaction is particularly easy to miss. With Origin Cache Control enabled, s-maxage implies shared-cache revalidation semantics that prevent Cloudflare from serving stale content, even when stale-while-revalidate is present. If browsers and Cloudflare need different TTLs while background revalidation remains active, send max-age with stale-while-revalidate from the origin and set Cloudflare’s Edge Cache TTL separately.
Leave behind a policy, not just a patch
The valuable result is not merely a higher hit rate. It is a cache policy the business can operate: which routes are public, which headers are authoritative, how purging works, who approves exceptions and how changes are verified.
If important pages keep returning BYPASS, DYNAMIC or unexplained repeated misses, Greg can audit the live responses, separate safe edge changes from application work, and provide a staged remediation plan. Talk to Greg about a Cloudflare cache audit.
Related on GrN.dk
- A stray Set-Cookie can waste your CDN: audit the cache at the edge
- Logistics Optimization in 2026: Fix the Flow Before You Buy More Tech
- NGINX 1.30 changed upstream connection reuse: what to check before you upgrade
Need help with this kind of work?
Talk to Greg about a Cloudflare cache audit Get in touch with Greg.