Cloudflare Cache Response Rules: Safer Header Fixes at the Edge

By Greg Nowak. Last updated 2026-07-23.

A public page should not need an application release simply because its response carries the wrong cache header. Cloudflare Cache Response Rules give operations teams a more direct option: adjust selected Cache-Control directives, manage cache tags, or strip particular headers after Cloudflare receives the origin response but before it decides how to cache that response.

This is useful for content sites, ecommerce category pages, campaign landing pages, documentation and other anonymous routes where avoidable origin requests affect performance and operating cost. It also gives agencies a bounded piece of work they can audit, test and hand back with clear ownership. The important word, however, is selected. Edge rules are a precision tool, not permission to cache every URL.

What Cache Response Rules actually change

Introduced in March 2026, the rules run in Cloudflare's http_response_cache_settings phase. They can modify individual cache directives, add or transform cache tags, and strip Set-Cookie, ETag or Last-Modified. They can match both request and response properties, including the hostname, path, method, response status and response headers.

They do not replace ordinary Cache Rules. Request-phase Cache Rules still decide whether an asset is eligible for caching. A Response Rule can repair headers on an eligible response, or make it uncacheable with no-store, but it cannot turn a request-time DYNAMIC decision into an eligible route by itself.

Start with evidence from real URLs

Build a sample containing commercially important pages, low-traffic pages, authenticated routes and at least one URL from each major template. Inspect a normal GET response rather than assuming a HEAD request behaves identically:

curl -sS -D - -o /dev/null https://www.example.com/important-page

Record CF-Cache-Status, Age, Cache-Control, Set-Cookie, ETag and Last-Modified. Repeat the request: a first MISS followed by a HIT is usually normal, while a persistent status points to a policy or eligibility decision.

The distinction between BYPASS and DYNAMIC is especially valuable. Since Cloudflare's May 2026 status update, BYPASS consistently identifies a response Cloudflare refused to cache after it was initially eligible. That makes it a strong lead for response-header cleanup. DYNAMIC normally sends you back to request-phase cache eligibility.

Choose safe candidates, not just easy ones

A good candidate is anonymous, repeatable and demonstrably identical between visitors. Examples include published articles, public documentation and landing pages without account-specific pricing or experiments. A poor candidate includes dashboards, carts, account pages, checkout flows, preview URLs and responses whose cookies control personalization, consent, currency or authentication.

Stripping Set-Cookie deserves the most scrutiny. First identify exactly what sets the cookie and whether removing it changes behaviour. Scope the rule narrowly by hostname, path, request method and response code. Test logged-out and logged-in journeys separately. If the team cannot explain the cookie, the safe decision is to leave it alone until they can.

Be equally careful with validators. Cloudflare states that stripping either ETag or Last-Modified disables Smart Edge Revalidation for that response. Removing them may solve one narrow problem while increasing later transfer or validation work.

A rollout that an operations team can own

1. Baseline: capture headers and cache status for a representative route set before changing configuration.
2. Classify: separate request-time eligibility problems from response-time header problems and genuine application dependencies.
3. Change one concern: do not combine eligibility, cache-key, cookie and TTL changes in one untraceable release.
4. Simulate and stage: use Cloudflare Trace to see whether rules would match. Where Version Management is available in your setup, keep response-rule changes inside a version and promote them through environments.
5. Verify live behaviour: repeat real requests, test authenticated journeys and confirm that the returned content, cookies, browser headers and purge process still behave correctly.
6. Monitor: watch route-level BYPASS, origin traffic and support reports, with a documented rollback owner.

One TTL trap is worth calling out. Cloudflare documents that s-maxage implies revalidation behaviour that prevents stale-while-revalidate from serving stale content. If browsers and Cloudflare need different TTLs while asynchronous revalidation remains enabled, use max-age with stale-while-revalidate in the origin policy and configure Cloudflare's Edge Cache TTL separately.

Make the edge fix part of a maintainable system

The immediate win may be fewer avoidable origin requests, but the durable output is a cache policy the team understands: which routes are public, which headers are authoritative, how content is purged, who approves exceptions and how changes are tested.

If your important public pages keep returning BYPASS or DYNAMIC, Greg can audit the live headers, separate safe edge changes from application work, and give your team a staged rollout plan. Talk to Greg about a Cloudflare cache audit.

Related on GrN.dk

• Cloudflare AI Gateway Puts LLM Budgets in the Request Path
• AI agents need a browser policy before they start clicking around
• AI automations need a spend dashboard before the first runaway bill

Need help with this kind of work?

Talk to Greg about a Cloudflare cache audit Get in touch with Greg.

Sources

• Cache Response Rules
• Cloudflare cache responses
• Revalidation
• Cache Response Rules now support zone versioning
• BYPASS status now returned for uncacheable responses