Vary Support Lands in Cloudflare Cache Rules With Normalize, Passthrough, Bypass

The Ugliest Part of HTTP Just Got Operable Guardrails

Cloudflare’s official engineering channel confirms that Vary support is now live in Cache Rules across Free, Pro, Business, and Enterprise plans.

The HTTP response header has long been one of the most dangerous mechanisms in shared caching: it prevents wrong-byte delivery, but it can also shatter a cache into thousands of single-use variants.

The new controls give operators a way to decide how much variation actually matters, instead of leaving the cache to compare raw request headers.

How Normalize, Passthrough, and Bypass Rebuild Cache Coherence

According to Cloudflare’s engineering blog, Vary works by telling an intermediary cache which request fields may affect the response an origin produces.

One URL can return HTML to a browser expecting markup and JSON to an API client, with the response selected by the ‘Accept’ header.

Without Vary, whichever representation enters the cache first can be served to both clients.

With Vary, the cache learns that the URL alone is not enough, but it still does not learn which differences are semantically important.

• normalize — Reduces equivalent request headers to a shared key before cache matching, with special handling for ‘Accept’, ‘Accept-Language’, and ‘Accept-Encoding’.
• passthrough — Preserves exact casing, whitespace, ordering, and duplicate values for cache keys when the precise value changes the response.
• bypass — Keeps responses out of cache for high-cardinality or personalized headers such as ‘Cookie’ or ‘User-Agent’.

Two requests can both prefer English, but carry different language tag orders, quality values, or casing.

A cache that treats raw values as distinct may store identical response bytes in separate entries.

Ten possible values across three headers can create 1,000 combinations, and real headers such as ‘User-Agent’ or ‘Cookie’ can have far higher cardinality.

An analysis of more than 120 million responses from nearly 50,000 popular sites found almost 3,000 sites varying on four or more fields.

Some sites varied on 10, 23, or even 47 fields, turning a technically correct cache into a nearly permanently cold one.

The origin still returns ‘Vary: Accept, Accept-Language’.

Cloudflare then reads the stored Vary fields and applies the configured action to the corresponding request headers.

If normalization was configured, Cloudflare can group several raw values under one cache key and forward the normalized value to the origin before the response is selected.

This ordering keeps the origin’s response selection aligned with the cache key.

If the response omits Vary, Cloudflare caches it normally; if ‘Vary: *’ appears, Cloudflare always bypasses cache.

Changing a Vary configuration does not automatically purge existing variants.

Old entries remain until expiry or purge, while new requests refill under the new keys.

A custom cache key adds dimensions to every response covered by a rule, whether the origin used them or not.

Vary is response-driven: the origin declares which headers matter, and the cache rule decides how to handle each declared field.

Cloudflare’s guidance is to use a custom cache key when a request property always defines the resource, and Vary when the origin names a consistent set of fields.

Where Cloudflare’s Vary Controls Sit in the Wider CDN Landscape

Google Cloud’s CDN documentation shows a different operational boundary.

Cloud CDN respects Vary only for a fixed allowlist of headers, including ‘Accept’, ‘Accept-Encoding’, ‘Origin’, and several ‘Sec-Fetch’ fields.

A response with any other Vary value, even under ‘FORCE_CACHE_ALL’, is simply not cached.

Cloudflare’s design does not force that kind of allowlist; it lets operators apply normalize, passthrough, or bypass to any header the origin names.

The contrast exposes a fundamental strategic decision for CDN providers: hard-code a safe set of negotiation fields, or ship guardrails and let operators tune the policy to their own application.

An IETF draft for ‘No-Vary-Search’ points to the next phase of this problem: extending the same stability to query strings.

The draft defines a response header that lets origins declare which URL query parameters do not affect the served response, so shared caches can ignore tracking parameters during matching.

It explicitly operates in addition to Vary, not as a replacement.

The proposal also warns that incorrectly marking a personalized or authorization parameter as no-vary could cause shared caches to serve one user’s response to another.

Cloudflare’s current Vary controls push in a similar direction by keeping the origin’s declaration and the operator’s cache policy tightly coupled.

The engineering team has also indicated it is evaluating ideas from the expired Availability Hints draft, which could let origins describe their supported representations directly and reduce manual media type and language configuration.

A Cache Key That Finally Matches the Origin’s Intent

Cloudflare’s Vary controls remove the long-standing false choice between serving the right response and maintaining a warm cache, giving performance teams a direct lever over negotiation fragmentation. For teams operating high-cardinality cache policies on WordPress infrastructure, WordPress speed engineering is how Andres SEO Expert approaches it — contact us.