Cloudflare Vary support is live in Cache Rules: how to choose normalize, passthrough or bypass

RULE CHANGE · 2026-09-22 · Cloudflare · Vary is now a Cache Rules setting

Sample and method: 30 homepages and the six sites we run, fetched once each on 26 September 2026 with curl, desktop Chrome user agent, redirects followed, no JavaScript executed. Response headers only. 28 of the 30 homepages returned 200.

Cloudflare Vary support became a Cache Rules setting on 22 September 2026, on every plan, and it replaces a choice that had no good answer. Vary is the response header that tells a shared cache which request fields helped select the response — usually Accept-Encoding when a body is compressed, or Accept-Language when it is translated. Before this release, a Cloudflare customer who needed it bypassed cache, built a custom cache key, or wrote a Worker. Now one setting decides how Cloudflare treats each header the origin names: normalize it, pass the exact value through, or keep the response out of cache. The default is normalize.

What Cloudflare Vary support actually adds

It splits one hard decision into two easy ones. The origin still names the fields in Vary; the Cache Rule decides how Cloudflare handles each named field's value. Cloudflare's post calls the header "the ugliest part of HTTP that we haven't yet improved", a phrase taken from Mark Nottingham's analysis of more than 120 million responses, so this is not a feature shipped casually.

Three actions are available, and the documentation is specific about the difference between them.

Two rules cut across that table. Vary: * always bypasses cache, because it says any part of the request may matter, including things outside the HTTP message such as the client's IP address. And changing the configuration does not purge what is already stored: requests refill under the new keys while old entries wait to expire.

What we checked on 30 homepages

We wanted to know how often this comes up, so we fetched 30 homepages once on 26 September 2026 and recorded what they send. Ten of the 28 that returned 200 were served through Cloudflare. Nine of the ten send a Vary header; eight of those nine send lowercase accept-encoding and nothing else.

The gap the feature is aimed at is visible in the last two rows and in our own sites. All six sites we run send the same five-field value — rsc, next-router-state-tree, next-router-prefetch, next-router-segment-prefetch and Accept-Encoding — and none of them sit behind Cloudflare, so nothing changes for us today. On a Cloudflare-fronted site, four of those five fields are framework routing tokens that a search crawler will never send. Naming them in Vary widens the cache key for infrastructure that may not need the distinction, and before this release the fix was to reproduce the origin's negotiation logic by hand.

One number here is smaller than it looks. Nine of ten is a statement about the homepages we happened to pick, not a rate for Cloudflare's fleet. We picked a developer-heavy panel, and it is not representative of the thousands of sites that use the platform for other things.

How to choose normalize, passthrough or bypass

Start from the default and only move off it with a reason. The order below is the one the documentation implies.

1. Leave negotiation headers on normalize. If your origin names Accept-Encoding or Accept-Language, equivalent requests should share a response, and normalize is what makes en-US, fr;q=0.8 and fr;q=0.8, en-GB collapse to the same variant.
2. Move personal or unbounded headers to bypass. Cookie and User-Agent are the documented examples. If a header can take thousands of values per visitor, keeping the response out of cache is cheaper than storing one copy each.
3. Choose passthrough only when the exact value changes the body. It preserves casing, whitespace, order and duplicates, so it is the wrong tool for a header the origin treats as equivalent.
4. Test with the same client and read CF-Cache-Status. Send requests that should normalize to one variant, then look for HIT once the cache fills. A persistent MISS or an unexpected BYPASS is the signal to revisit the rule.

Do not put the same header in both a custom cache key and Vary unless you have tested the duplication. The documentation's rule is that a custom key fits a property that always defines the resource, while Vary fits a set of request fields the origin declares across its cacheable responses.

What it does not do

It does not fix an origin that omits Vary, and the post is explicit that a response without it is cached normally. It does not purge existing content. And it is not something we could observe directly: we do not run this setting on Cloudflare, so everything above about behavior comes from Cloudflare's documentation and post, while the numbers come from response headers. We did not send varied request headers to see whether a body changed, so this measures what sites declare, not what a cache stored.

That last gap is the honest limitation of the piece, and we cannot close it from here. The declarations we counted are real; the effect on a cache is documented, not tested by us.

Common questions

What is the Vary header for?

It tells shared caches which request fields may change a response, so a cache does not serve a compressed body to a client that did not ask for one. RFC 9110 defines it and states that it "expands the cache key required to match a new request to the stored cache entry".

Does Vary affect SEO?

Not as a ranking input, and no Google documentation describes it as one. It matters through delivery: a crawler is a cache requester too, and the header decides which stored copy a shared cache hands back. The declarations across 27 homepages are counted in the Vary header survey.

Why not just add a custom cache key?

Because a custom key adds its dimensions to every response covered by the rule, whether the origin used them or not. Vary is response-driven, so it only widens the key for the responses that actually name the field.

How did you measure this?

One request per homepage on 26 September 2026, desktop Chrome user agent, redirects followed, response headers stored as received. Two sites returned 403 and were dropped, leaving 28. We read declarations only and did not test any cache's behavior.

The change matters most to sites that run the same framework we do: four routing fields in Vary are inert for a crawler, and until September there was no one-line way to say so on Cloudflare. What compression those fields negotiate is counted in content-encoding across 27 homepages, the hit-rate side is in CF-Cache-Status across the panel, and turning all of it into a change you actually publish is the part QueryWin works on.