Some pages on a site hit the CDN cache while others reach the origin on every request. The dashboard may also report that certain requests bypass caching. This usually follows response headers, cookies, request methods, or path rules rather than a random cache failure.
Start by separating responses that must remain private from public content that should be cacheable. Do not delete Set-Cookie or ignore login cookies just to raise the hit ratio. An incorrectly configured shared cache can serve one user's response to another user.
Separate the different kinds of cache misses
A MISS or BYPASS label may indicate a missing object, a response that must not be stored, a cookie-related exception, or a path configured to go directly to the origin. The meanings are provider-specific. Record the status and its documented definition, then compare it with the origin response headers.
Choose a small, public HTML or JSON test response that does not depend on login state. Capture:
the method, full URL, and query parameters;
Cache-Control,Expires,Age,ETag, andVary;whether the response includes
Set-Cookie;the CDN cache status, matching rule, and request trace ID;
body digests and origin access records for repeated requests.
Do not copy real session cookies into a public test environment. Record whether a browser cache, service worker, or another proxy sits in the request path.
Cache-Control explains many default decisions
Cache-Control: no-store tells a cache not to store the response. no-cache permits storage but requires successful validation before reuse. private restricts storage by shared caches. Check both the origin directives and the CDN's configured behavior; product-specific overrides must be understood before changing them.[1]
If an application framework marks every HTML response private or no-store, public pages may consistently bypass shared caching. Conversely, forcing the edge to ignore these directives can place authenticated pages, carts, or personalized APIs in a shared cache.
Review public static assets, public HTML, personalized HTML, APIs, and downloads separately. For each group, define when caching is allowed, how long a response can remain fresh, and how it is invalidated.
Set-Cookie requires a provider-specific check
Set-Cookie often means that the application is creating or updating a session. Many CDNs treat it as a reason to bypass caching or apply special handling. This is not a universal HTTP prohibition: RFC 9111 notes that Set-Cookie alone does not prevent caching. The actual outcome depends on cache directives and provider rules.[1] Do not assume either that it will always bypass the cache or that it is safe to store publicly.
Check whether the application sets a tracking, experiment, or empty-session cookie on every otherwise public page. Determine whether that state changes the response body. Application-side changes or client-side state handling may be appropriate, but validate the behavior in staging before removing any header.
Keep authenticated, permission-dependent, and cart responses isolated from shared caching. For truly public assets, a dedicated hostname, versioned filenames, and explicit cache headers are generally easier to maintain than ambiguous edge exceptions.
Request variants can fragment the cache
Vary and custom cache keys can separate responses by Accept-Language, Accept-Encoding, device signals, or selected cookies. More variants can reduce reuse. Omitting a value that genuinely changes the response can instead combine incompatible content.[1][2]
Compare anomalous requests for the following differences:
whether gzip, Brotli, and unencoded responses are stored separately;
whether language negotiation creates too many variants;
whether cookies and custom headers actually change the body;
whether all query parameters enter the cache key;
whether path-specific rules override origin cache directives.
Do not remove tenant, authorization, or language distinctions merely to reduce object count. Establish the business meaning of each variation before normalizing it.
Verify the actual behavior with controlled requests
These examples assume a Unix-like shell and curl. Replace the hostname and path with an authorized public test object. Do not add real login cookies.
curl -sS --max-time 10 \ -D response-1.headers -o response-1.body \ 'https://cdn.example.com/public/test.html' curl -sS --max-time 10 \ -H 'Accept-Encoding: gzip, br' \ -D response-2.headers -o response-2.body \ 'https://cdn.example.com/public/test.html'
Record Cache-Control, Vary, Set-Cookie, Age, and the CDN cache status. Different statuses do not independently prove a fault; they may reflect separate cache keys or encoding variants. These commands do not request automatic decompression. Decode each body according to its actual Content-Encoding before comparing content digests, and use the second request only where the response encoding can be inspected reliably.
A single pair of requests does not establish stable cache behavior. Repeat the same variant and correlate it with origin logs. Avoid random query parameters that create new objects and additional origin traffic.
Fix privacy boundaries before improving hit rates
First confirm that login, authorization, cart, and user-specific API responses cannot enter an inappropriate shared cache. Then improve reuse for public pages and static assets. Correct origin headers, remove unnecessary state only after checking application behavior, use versioned URLs, and keep separate rules for different content groups.
Change one path group or cache condition at a time. Save the previous configuration and define how to roll it back. Verify body content, cache status, origin request volume, errors, and latency together. A site-wide purge cannot repair an incorrect rule, and sustained cache-busting tests can create their own origin-load problem.
The investigation should explain which responses may be shared, which require origin processing or private handling, and whether low reuse follows a deliberate rule or excessive variants. A higher hit ratio is not sufficient acceptance evidence if users' responses are no longer isolated.
References
Source review date: November 11, 2026. Commands are controlled read-only examples; no testing in the reader's production environment is claimed.
