CDN Cache Bypass Rules Explained: Cookies, Query Strings, and Headers

Overview

Most CDN cache bypass problems look similar from the outside: low cache hit ratio, inconsistent TTFB, repeated origin requests for assets that should be served from the edge, or entire page types that never seem to cache. In practice, the causes are usually more specific. A request arrives with a session cookie. A cache key includes query strings that should have been normalized. An origin sends Cache-Control: private or no-store. A response contains Set-Cookie on otherwise public content. A custom rule at the CDN layer overrides default behavior.

Understanding those signals matters because modern website caching is layered. You may have browser caching, a reverse proxy cache, application cache, object cache, and an edge delivery network all making decisions independently. A page that is cacheable in Nginx or Varnish may still bypass a CDN for websites if the request or response matches a no-cache condition at the edge. That is why troubleshooting must start with a request-by-request approach rather than broad assumptions.

At a high level, CDN cache bypass usually happens for one of five reasons:

• Request cookies mark a user as personalized or authenticated.
• Query strings create too many URL variants or trigger dynamic handling.
• Request or response headers explicitly prevent caching or force revalidation.
• Path-based rules exclude sections like admin, cart, checkout, account, or API endpoints.
• CDN configuration uses custom bypass logic, origin shields, or cache key settings that do not match the application.

The goal is not to cache everything. Good edge caching is selective. Public HTML, static assets, and stable API responses are usually strong candidates. Personalized pages, logged-in sessions, and transactional workflows should often bypass. The real work is defining that boundary clearly and keeping it accurate over time.

If you are still building a broader caching baseline, it helps to review How to Improve Cache Hit Ratio on a CDN and the HTTP Cache-Control Header Reference for Developers before tuning vendor-specific rules.

Maintenance cycle

This topic benefits from a regular review cycle because cache bypass behavior drifts as applications change. A plugin update adds a new cookie. Marketing tools append tracking parameters. A framework changes default headers. A new account area goes live under an existing path. None of these changes are dramatic on their own, but each can quietly reduce edge caching.

A practical maintenance cycle looks like this:

1. Monthly: sample representative URLs and inspect request and response headers.
2. After major releases: retest page types affected by authentication, cart logic, personalization, search, and API output.
3. Quarterly: audit cookies, query parameters, bypass rules, and cache key design as a set.
4. After CDN or hosting changes: compare current behavior with previous baseline results.

During each review, test at least these page classes:

• Homepage and top landing pages
• Blog or documentation content
• Static assets such as CSS, JS, fonts, and images
• Product or catalog pages
• Cart, checkout, login, and account pages
• Search results and filtered listing pages
• API routes that are intended to be cacheable

Use a simple worksheet or runbook with columns for URL, expected cacheability, cookies present, query strings present, cache-control headers, response status, CDN cache status, and notes. The point is to record what should happen, then compare it with what actually happens. This keeps your troubleshooting grounded and makes regressions easier to spot later.

For WordPress caching and eCommerce sites, this discipline is especially useful. A theme update or plugin change can add session-related behavior to public pages. If you manage WooCommerce, review WooCommerce Caching Rules: What to Cache and What to Bypass alongside your CDN cache bypass policy.

A maintenance cycle should also include purge strategy review. Teams sometimes compensate for unclear bypass logic by over-purging, which reduces the value of edge caching and increases origin load. If you need a safer framework for invalidation, see How to Purge CDN Cache Without Breaking Your Site.

Signals that require updates

You should revisit your CDN cache bypass rules whenever new request patterns, content types, or delivery logic appear. The most important signals are usually visible in logs, response headers, or application releases.

1. New or changed cookies

Cookies are one of the most common reasons content stops caching. Many CDNs treat requests with cookies cautiously by default, especially for HTML. That is reasonable, but it can become too broad if harmless cookies are treated like session state.

Look for:

• Analytics or A/B testing cookies on anonymous pages
• Consent or preference cookies that do not alter core content
• CMS preview or editor cookies leaking beyond admin paths
• Application session cookies appearing on guest traffic
• Set-Cookie headers on responses that should otherwise be public

The key question is not simply “Is there a cookie?” but “Does this cookie actually change the response body for this page type?” If the answer is no, you may be able to ignore that cookie in the cache decision or strip it before the request reaches cacheable content. If the answer is yes, bypass is usually correct.

2. Query string growth

Query string caching can either improve precision or destroy cache efficiency. Some parameters produce meaningfully different content, such as pagination, language, filters, or an image transformation signature. Others do not change the response and only fragment the cache, such as many campaign tags.

Review:

• Tracking parameters like UTM variants
• Sort and filter combinations on category pages
• Search parameters
• Cache-busting parameters added by build systems or plugins
• Signed URLs for assets or downloads

A useful rule of thumb is to decide which parameters belong in the cache key and which should be ignored or normalized. If every unique query string becomes a new cache object, your hit ratio can collapse even when the content is practically identical.

3. Header changes from origin or application framework

Headers often explain why CDN not caching behavior appears inconsistent. The most important ones to inspect are:

• Cache-Control
• Expires
• Vary
• Set-Cookie
• Authorization on the request
• Vendor-specific cache status headers

Headers that commonly bypass or limit cache include no-store, private, and sometimes no-cache depending on how the CDN interprets revalidation. A broad Vary header can also reduce cache reuse. For example, Vary: Cookie or uncontrolled variation by custom request headers can create a near one-request-one-object pattern.

If you need a deeper refresher on response directives, pair this article with HTTP Cache-Control Header Reference for Developers and ETag vs Last-Modified: Which Revalidation Strategy Should You Use?.

4. Platform or vendor changes

Even if your own app does not change, your stack might. Moving from one CDN to another, enabling a managed caching solution, introducing a reverse proxy cache, or updating a framework can all change defaults around query string caching, cookie handling, and cache key construction. This is one reason a troubleshooting article like this should be revisited periodically.

If you are comparing providers or evaluating how different platforms approach edge delivery network features, see Cloudflare vs Bunny.net vs Fastly: CDN Features and Pricing Compared and Best CDN Services for Small Business Websites.

Common issues

Below are the most frequent cache bypass scenarios, along with a practical way to investigate each one.

Public pages bypass because of non-essential cookies

This often happens on content sites and WordPress caching setups. A consent banner, analytics script, or personalization tool sets a cookie on every visitor, and the CDN interprets all cookie-bearing requests as dynamic. The result is that anonymous traffic misses edge caching even though the page is otherwise public.

What to check:

• Whether the cookie changes the HTML output
• Whether the bypass rule targets all cookies or only specific names
• Whether the response sets a cookie unnecessarily

What to do: Narrow bypass rules to session or auth cookies only, and keep preference or analytics cookies out of the cache decision when safe. On WordPress, also check plugins that emit cookies outside logged-in experiences. Related reading: Best WordPress Caching Plugins Compared and How to Set Up Nginx FastCGI Cache for WordPress.

Static assets miss cache because of query string versioning

Asset versioning is common and usually helpful, but some CDN configurations treat each parameterized URL conservatively or do not cache as expected unless rules are explicit. If your CSS and JS files are requested as style.css?v=123, verify whether your CDN for websites caches that variant and how long it keeps it.

What to check:

• Whether assets with query strings are cacheable at the edge
• Whether the cache key includes all query params by default
• Whether your build process appends unnecessary random values

What to do: Keep versioning deterministic, prefer filename fingerprinting where possible, and avoid cache-busting patterns that generate unbounded variants.

HTML bypass because the origin sends private or no-store

This is often a correct origin instruction, but sometimes it is applied too broadly by middleware, frameworks, or security plugins. Developers may ship safe defaults for dynamic pages and accidentally attach them to public pages as well.

What to check:

• Origin response headers on cacheable page types
• Framework defaults for authenticated and anonymous routes
• Whether intermediate proxies are rewriting headers

What to do: Set route-level cache behavior intentionally. Public pages should receive public cache directives. Personalized routes should remain private or bypassed.

Authorization or custom headers create hidden cache fragmentation

Some requests are never served from CDN cache because they carry authorization headers, preview headers, geo or experiment headers, or other request metadata that alters the cache key. In some stacks, these headers are present even for traffic that should have been anonymous.

What to check:

• Whether client-side code sends auth headers to public endpoints
• Whether preview or debugging headers leak into production traffic
• Whether Vary includes headers that are too broad

What to do: Reduce variation to only the headers that truly affect the response, and separate authenticated endpoints from cacheable public delivery where possible.

eCommerce paths cache incorrectly or bypass too much

Commerce applications often need finer control than a simple “cache all” or “bypass all” rule. Product pages may be cacheable for guests, while cart, checkout, account, and some pricing logic should bypass. If your rules are too broad, you lose performance. If they are too loose, you risk serving personalized content incorrectly.

What to check:

• Cookie names used for cart and session state
• Path patterns for account and checkout flows
• Whether add-to-cart or stock state affects otherwise public pages

What to do: Build explicit allow and bypass rules by page type, cookie, and method. For many sites, GET requests to public catalog pages are cacheable, while authenticated or transactional requests are not.

API caching strategy is undefined

Teams often focus on HTML and assets while leaving APIs uncached or accidentally bypassed. Some APIs are highly cacheable, especially read-heavy, public, or infrequently changing responses. Others should not be cached at all.

What to check:

• Whether response headers define cacheability clearly
• Whether query strings create too many variants
• Whether authorization is present on requests intended to be public

What to do: Design an API caching strategy endpoint by endpoint instead of applying one rule to all APIs.

When to revisit

Revisit your CDN cache bypass rules on a schedule and after any change that affects request identity or response variability. In practical terms, that means after plugin installations, framework upgrades, authentication changes, checkout updates, CDN migrations, or marketing tooling changes that add parameters or cookies.

A useful review checklist is:

1. Pick ten representative URLs across static, public HTML, transactional, account, and API content.
2. Test as anonymous and logged-in users where relevant.
3. Inspect cookies, query strings, and request headers before the request reaches origin.
4. Inspect response headers from origin and from the CDN edge.
5. Confirm expected cache status and note any unexpected bypass.
6. Review cache key logic for parameters and varying headers.
7. Update documentation so future changes can be checked against a baseline.

If you only do one thing after reading this article, do this: create a small matrix of page types and define, in writing, whether each one should be cached, bypassed, or revalidated. Then map the exact cookie names, query parameters, and headers that justify each decision. That single document will make future troubleshooting faster, reduce accidental origin load, and improve website speed optimization without forcing risky blanket cache rules.

Finally, treat this as a recurring maintenance topic rather than a one-time setup task. Cache behavior evolves with the application. Revisiting it quarterly is usually enough for stable sites, while active eCommerce and app platforms may need review after every significant release. When search intent, platform defaults, or your own architecture changes, update the rules and rerun the tests.

For related maintenance work, you may also want to review CDN Pricing Comparison Calculator Inputs: What Costs to Estimate Before You Choose if origin traffic is rising, since poor cacheability often affects both performance and cost.