When the same URL serves different pages depending on language or format, the cache needs to know which request differences change the response. Since September, Cloudflare Cache Rules support the HTTP Vary header on every plan. It lets the same URL have separately cached responses based on a request header such as Accept-Language. That helps prevent the cache from serving, for example, a Portuguese version to someone who requested the page in English.
The header solves only half the problem. Browsers can send different values that express the same preference. If every raw string becomes a separate key, the cache fills with copies that are rarely reused. If important differences are ignored, the wrong response may reach a visitor. The configuration now requires a decision about which differences actually change the content.
Normalize equivalent values
In Cloudflare rules, normalize converts known values into a common form before selecting a cached copy. For Accept, Accept-Language, and Accept-Encoding, teams can limit the recognized formats or languages. Equivalent preferences can then use the same cached response.
This is often a good starting point when the server provides a small, predictable set of variants. The team can limit the accepted formats or languages so small differences in request headers do not create additional copies. Normalization is safe only when the configured set matches the responses the server actually provides.
For other headers, normalization is more limited: optional whitespace is removed and repeated lines are combined, but differences within the values may remain. Check the documentation before assuming that two custom values will be treated as equivalent.
Preserve or bypass when appropriate
With passthrough, Cloudflare uses the raw header value to select a cached copy. Differences in capitalization, whitespace, and order can create separate responses. That may be necessary when the exact value changes the content, but it can also multiply cache keys. Use it only when the distinction has a real effect on the response.
With bypass, the response is not stored if the server lists that header in Vary. This is the safer choice for personal or unpredictable values such as Cookie when no rule makes the response safe to share. The tradeoff is losing the cache for those responses; existing entries remain until they are removed or expire.
These actions apply only when the server's response includes Vary. Adding a rule alone does not make Cloudflare create variants for every response. First confirm that the server declares the right headers and that the route is eligible for caching.
Check both the response and reuse
Test the same URL with values that should receive identical content and values that need different responses. Then check whether the first visit populates the cache and later visits reuse the expected variant. For normalized values, different but equivalent headers should converge; for preserved values, the separation should match a visible difference in the response.
You can also purge every variant of a URL with a URL purge. That helps while changing a rule, but it does not replace testing: a configuration can improve reuse and still serve incorrect content if the server's Vary declaration is incomplete.
The practical criterion is simple: normalize presentation differences that do not change the response, preserve those that do, and leave personal or unpredictable responses uncached. The rule is easier to maintain when each header has a reason tied to the content being delivered.
If your company is weighing something similar, reach me on LinkedIn or WhatsApp.
