By Greg Nowak. Last updated 2026-10-18.
A public article that returns BYPASS on every visit can send avoidable traffic to your origin. Sometimes the cause is a header the application should change, but an application release may take time. Cloudflare Cache Response Rules offer a way to correct selected response headers at the edge while the permanent fix is planned.
The important decision comes first: is this page genuinely the same for every visitor? A better cache hit rate is no win if a preview, account detail or personalised price reaches someone else. Start with the live response and a clearly defined set of public routes.
Cache Rule or Cache Response Rule?
A Cache Rule looks at the request and decides whether the URL is eligible for caching, under which key and for how long. A Cache Response Rule looks at the origin's response and can rewrite Cache-Control, change cache tags or strip Set-Cookie, ETag and Last-Modified before Cloudflare decides whether to store it. In practice: DYNAMIC is a Cache Rule problem, BYPASS is usually a Cache Response Rule problem. Response Rules exist on every plan (10 rules on Free, 25 on Pro, 50 on Business, 300 on Enterprise) and are the only place to override origin cache headers; a Worker or a Response Header Transform Rule runs after the cache decision and cannot change it.
Find out why the page is not caching
Cache Rules evaluate the incoming request and decide whether it is eligible for caching. Cache Response Rules run after Cloudflare receives the origin response, before the cache decision. They can change Cache-Control directives, manage cache tags or strip specific headers, but they cannot make an ineligible request eligible. A typical HTML page may need a Cache Rule first.
Use a real GET request and save the headers for a representative public URL:
curl -sS -D - -o /dev/null https://www.example.com/articles/exampleLook at CF-Cache-Status, Cache-Control, CDN-Cache-Control, Set-Cookie, Vary, Age and CF-Ray. Also check what the origin sends: its Cloudflare-CDN-Cache-Control header, if present, is not shown to visitors. Make the request again from the same client and compare the data-centre code at the end of CF-Ray. A first MISS after a purge is expected.
| Cache status | What to check next |
|---|---|
DYNAMIC |
The request was ineligible. Check Cache Rules, request method and Development Mode. |
BYPASS |
The request was eligible, but the response was not stored. Inspect cache directives, Set-Cookie, Vary: *, authorisation and object size. |
Repeated MISS |
Compare cache keys, changing query strings, recent purges and whether requests reach the same data centre. |
HIT |
Check that the content, freshness period and purge process are correct. |
CF-Cache-Status to the next investigation step.A BYPASS does not automatically mean Cache-Control is wrong. Cloudflare’s uncached-response guidance lists several other causes. Diagnose the cause before choosing a header fix.
Decide which responses may be shared
Good candidates are published articles, public documentation and campaign pages whose content is identical for anonymous visitors. Treat carts, checkout, account pages, previews and dashboards as separate work. Cookies can also affect currency, consent, experiments or logged-in navigation on an otherwise public-looking page.
If the origin sends Set-Cookie, find out which system creates it and what it does before stripping it. Test both logged-out and logged-in visits. If the team cannot explain the cookie or the page variations, keep that route out of the rule.
Keep validators unless there is a specific reason to remove them. ETag and Last-Modified can make revalidation more efficient. Cloudflare says stripping either with a Cache Response Rule disables Smart Edge Revalidation for that response. Removing a header solely to improve today’s cache status can create more origin work later.
Make one small, reviewable rule
In the Cloudflare dashboard, go to Cache > Cache Rules > Cache Response Rules. Name the rule for the route and the problem it fixes. Match the exact hostname, a specific path family, GET or HEAD, and an appropriate origin response code such as 200. Exclude preview and administration paths and requests carrying session state. Cloudflare’s rule settings support matching on both request and response fields.
Then change only the directive or header you have proved is blocking the intended cache policy. For example, if a published article is incorrectly marked private, confirm that the response is truly public before removing that directive for the narrow route. If browsers should keep the origin’s directive while Cloudflare uses a different one, consider the Cloudflare only setting. It changes Cloudflare’s cache handling without changing the directive visitors receive.
Review the full rule stack before enabling the change. A matching Cache Response Rule defaults to Origin Cache Control behaviour, takes precedence over conflicting Cache Rule settings, and stacks with other Response Rules; the last matching rule wins for the same setting. Use Cloudflare Trace to see which rules match the URL. Set a freshness period that fits how the team publishes updates and purges pages.
Verify the page, then keep an owner for the policy
Record headers and page behaviour before the change. After rollout, repeat the request from the same client, check the cache status and inspect the page itself. Test the relevant templates plus logged-in, preview, consent and commerce journeys. Watch origin traffic and cache statuses by route, and keep the previous rule configuration available for rollback.
One freshness detail deserves a separate check. With Origin Cache Control enabled, s-maxage prevents Cloudflare from serving stale content even when stale-while-revalidate is present. If you need different browser and edge lifetimes with background revalidation, Cloudflare recommends max-age with stale-while-revalidate at the origin and a separate Edge Cache TTL in Cache Rules.
The lasting result should be a policy the team can operate: which routes are public, who owns their headers, when to purge and how to check a change. If your site has a mix of BYPASS, DYNAMIC and unexplained misses, talk to Greg about a focused Cloudflare cache audit.
Quick answers
Can a Cache Response Rule make a DYNAMIC page cacheable?
No. Eligibility is decided by Cache Rules on the request. Add a Cache Rule for the route first, then use a Response Rule for whatever header still produces BYPASS.
Does it run on responses Cloudflare does not cache?
Yes. The rule runs on every matching origin response, cached or not, so it can strip a Set-Cookie from a response that stays dynamic.
Which wins when a Cache Rule and a Cache Response Rule disagree?
The Response Rule. Once any Response Rule matches, Cloudflare also switches to Origin Cache Control behaviour for that response, and among several matching Response Rules the last one wins for the same setting. Check with Cloudflare Trace before enabling.
Related on GrN.dk
- A stray Set-Cookie can waste your CDN: audit the cache at the edge
- Your AI Gateway Can Name the User. Decide What That Log Is For
- 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.
