Cloudflare has announced new controls for responses that vary between requests. Before tuning public variants, establish a simpler boundary: an authenticated session should not accidentally reuse another visitor's cached page.
1. Find the cookie your application actually sends
Sign in to a test copy of the application and inspect outgoing cookies in the browser's network tools. Record the cookie name that accompanies authenticated requests, without copying its secret value into notes or a support ticket.
The name member_session below is invented for this example. WordPress plugins and other applications may use entirely different names. Confirm the relevant marker with the person maintaining the application.
Prepare three independent browser profiles: an anonymous visitor, test account A and test account B. Give the accounts visibly different demonstration names so that an unexpected response is easy to recognize.
List personalized pages that do not carry this cookie too. An anonymous basket or a different session mechanism needs its own analysis. A cookie-based exception is a specific control, not proof that every private response is covered.
2. Add a focused cache bypass
Under Caching, open Cache Rules and create a condition combining the exact hostname with the observed cookie marker. Adapt this example:
(http.host eq "shop.example.com" and http.cookie contains "member_session=")Select Bypass cache for Cache eligibility. This example performs a substring check against the cookie header, so confirm that the application's real requests match the chosen text.
Review other cache rules that could affect the same traffic. The existence of one correctly named rule is not sufficient evidence of the final behavior when several settings interact.
If private responses might already have been cached, arrange to purge the affected content. Do not assume that editing a policy proves previously stored objects have been removed. Keep the existing configuration available while you validate the replacement.
3. Compare responses across identities
Load the same page repeatedly as A, as B and as the anonymous visitor. Use separate profiles rather than signing in and out in a shared browser session.
Inspect response headers and visible content in the network panel. A private response carrying a HIT cache status needs investigation. Conversely, a single response without HIT does not establish that every personalized page is correctly isolated.
Test deep links, logout and a return to a previously visited page. The acceptance condition is about content: each profile must receive only its own expected state.
Keep this small test matrix with the cache rule. Run it again after a session-cookie change, a relevant plugin update or a new caching policy, because any of those can invalidate the assumptions behind the original match.
Sources: Cloudflare Blog, Cloudflare documentation.
See it in our social posts
The key steps of this article, as a carousel. Follow us to catch the next ones.