Cloudflare's Vary Support: Decide What Variation Your Cache Can Afford

One URL can legitimately have several correct responses. A browser wants HTML, an API client wants JSON, and both hit the same path. The Vary response header is how an origin tells a cache which request fields may change the answer. It is also, per the Cloudflare post, a mechanism with “pretty abysmal interoperability” across intermediaries.

On 2026-09-22, Cloudflare shipped Vary support in Cache Rules on every plan. The origin still declares which request headers may affect a response. What changes is that you now decide how Cloudflare treats each one, instead of leaving the cache to compare raw header strings.

The failure mode is a correct but cold cache

The supplied Cloudflare post describes the core problem plainly: Vary says which fields may matter, not which differences actually do. An origin that serves only English, French, and German may receive Accept-Language: en-US, fr;q=0.8 and Accept-Language: fr;q=0.8, en-GB. Both prefer English. A cache comparing raw values cannot assume they are equivalent, so it stores separate variants even when the bytes are identical.

That compounds. Ten values across one field is ten variants; ten values across three fields can be 1,000 combinations. Cloudflare cites an analysis of more than 120 million responses from nearly 50,000 popular sites, where almost 3,000 sites varied on four or more fields, and some varied on 10, 23, or even 47 fields. The cache stays correct and almost permanently cold, evicting entries it can never merge.

Three actions, three different bets

Cache Rules split the decision in two: the origin names the headers, and the rule decides how Cloudflare handles each value. Headers without an individual setting fall back to the rule’s default action.

• Normalize is the recommended default. Cloudflare lowercases Accept, Accept-Language, and Accept-Encoding, sorts by quality value, and can keep only configured media types or languages. Regional tags like en-US reduce to en unless the full tag is configured.
• Passthrough preserves exact values, including casing, whitespace, ordering, and duplicates. Use it when the precise value changes the response.
• Bypass skips storing the response. Use it for headers with personal or unbounded values.

Two details matter for correctness. Vary: * always bypasses cache, because any aspect of the request may affect the response. And Cloudflare forwards normalized Accept and Accept-Language values to the origin, so origin selection stays aligned with cache matching rather than diverging from it.

What this changes in your build

The origin now carries more responsibility than before. Every cacheable response that can differ by request field must return the right Vary header consistently, including errors and fallbacks. If one response omits it, Cloudflare may cache that response without the isolation it needed.

There is also an operational gap worth planning for: changing a Vary configuration does not automatically purge existing content. New keys refill on miss while old entries linger until they expire or are purged. Purges targeting a resource cover all its variants.

If you already run edge logic, this is the same class of decision as picking a runtime before a model. The earlier post on Python Workers reaching GA makes a similar point about the edge: the platform’s defaults shape what you can cache, route, and reason about later. Here, the practical move is to start with normalize as the default, reserve passthrough for headers where the exact value genuinely changes the bytes, and send anything personal or unbounded to bypass.

The supplied Cloudflare post does not specify how normalization interacts with every existing cache-key feature, so treat that as something to verify against your own configuration before rolling it out broadly.

Sources

• We just shipped support for the ugliest part of HTTP: Vary

AI-assisted summary compiled from the sources above, reviewed by a human before publishing.