How Cloudflare Caches Multiple Versions of the Same URL

Edge caching has always been built around one simple assumption: one URL maps to one cached object.That assumption powered CDNs for years because most websites returned the same content to everyone. When someone requested example.com/index.html, the CDN only had to answer one question: Have I already cached this URL? If the answer was yes, it could serve the response immediately without contacting the origin.

Modern web applications don't work that way anymore.The same URL might return different languages, different image formats, or even different content depending on who's making the request. A visitor in Spain expects Spanish, someone in the UK expects English, Chrome prefers AVIF images, while Safari may need JPEG instead. The address stays the same, but the response changes.HTTP has supported this idea for years through content negotiation, but caching those variations efficiently across a global CDN has always been one of the hardest parts of edge caching.

Cloudflare's new native support for the Vary header in Cache Rules changes that. Instead of forcing developers to choose between personalization and cache performance, Cloudflare can now cache multiple representations of the same URL while keeping cache efficiency high.

Let's look at why this has been such a difficult problem and how Cloudflare solved it.

One URL, Multiple Responses

Every HTTP request carries more than just a URL.

Browsers also send request headers describing what they prefer to receive. The origin uses those headers to decide which version of a resource should be returned.

Some common examples include:

• Accept-Language – preferred language
• Accept – supported image formats such as AVIF or WebP
• User-Agent – browser and device information

Because of those headers, the same URL can legitimately return different responses.

For example:

• A visitor in Spain receives a Spanish page.
• A visitor in the UK receives an English page.
• Chrome downloads an AVIF image.
• Safari receives a JPEG version instead.

The URL never changes.

Only the representation of the resource changes.

To make caches aware of this behavior, the origin includes a response header like:

Vary: Accept-Language, Accept

This tells every cache that the URL alone is no longer enough to identify the response. These request headers are also part of deciding which cached version should be served.

Why Traditional CDNs Struggled

The HTTP specification has supported the Vary header for years. The challenge hasn't been understanding what it does; it's implementing it efficiently across a global CDN. That challenge begins with the request headers themselves.

Consider these two requests:

Accept-Language: en-US, fr;q=0.8

and

Accept-Language: fr;q=0.8, en-GB

To a traditional cache, those two headers are completely different strings. Because cache keys are built from those values, the cache treats them as different requests and stores separate cached objects for each one, even though both users are simply expressing a preference for English.

Now multiply those small differences across millions of users, browsers, operating systems, and browser extensions. Before long, the cache fills with duplicate copies of nearly identical content, each occupying space that could have been used more efficiently.

This problem is known as cache key fragmentation. Instead of improving cache efficiency, fragmentation works against it. Cache hit ratios drop, more requests are forwarded to the origin, latency increases, and infrastructure costs begin to rise.

The Workarounds Developers Used

Before native Vary support, there wasn't a perfect solution. Developers typically chose one of three approaches, each solving one problem while creating another.

The simplest option was to bypass the cache entirely. It guaranteed that every visitor received the correct response, but every request still had to reach the origin. As traffic increased, so did latency and server load, making this approach difficult to scale.

Another common solution was restructuring URLs instead of relying on request headers. Applications exposed separate paths such as example.com/en/ and example.com/es/, allowing each variation to be cached independently. While this made caching straightforward, it also introduced additional routing logic, more URLs to maintain, and extra SEO considerations.

Many teams eventually solved the problem with edge computing. Cloudflare Workers and similar platforms allowed developers to inspect request headers and generate custom cache keys manually. It was a flexible solution, but it also meant writing and maintaining code simply to teach the CDN something the HTTP protocol had already described.

Cloudflare's New Approach

Cloudflare's new approach moves this capability directly into Cache Rules. When native Vary support is enabled, Cloudflare reads the Vary header returned by the origin and automatically incorporates those request headers into the cache key. Instead of relying on custom Workers or application logic, the CDN can now understand which request headers define a unique representation of a resource.

The request flow looks like this:

      Incoming Request
             │
             ▼  
      Cloudflare Edge
             │
             ▼
   Vary Cache Rule Engine
             │
 ┌───────────┼──────────┐
 ▼           ▼          ▼
Normalize Passthrough Bypass

The important change is that the cache key is no longer built from the URL alone. Depending on how each header is configured, Cloudflare can normalize it, preserve it exactly as received, or bypass caching altogether.

Normalize

For most applications, Normalize is the mode that delivers the biggest benefit. Instead of comparing request headers character by character, Cloudflare understands when different header values express the same intent.

Consider these two requests:

Accept-Language: en-US, fr;q=0.8

Accept-Language: fr;q=0.8, en-GB

Although the header values are different, both requests ultimately express the same preference for English. Rather than creating two separate cache entries, Cloudflare maps both requests to the same cached object.

The important part isn't comparing header values differently. It's recognizing when different header values describe the same representation of a resource. By avoiding duplicate cache entries, Cloudflare improves cache efficiency while reducing unnecessary storage.

The result is straightforward:

• Fewer duplicate objects
• Higher cache hit ratios
• Less storage waste
• Better edge performance

Passthrough

Not every application can normalize request headers. Some APIs, versioned services, and internal systems depend on exact header values, where even a small difference changes the response.

For these scenarios, Cloudflare provides Passthrough mode. Rather than interpreting or normalizing the header, Cloudflare preserves the complete value exactly as it was received and uses that precise value when generating the cache key. This ensures that every unique request continues to receive the correct cached representation.

Bypass

Some request headers should never participate in caching. Headers such as authorization tokens or session identifiers would generate an almost unlimited number of cache variations, making caching ineffective and potentially unsafe.

For these situations, Cloudflare provides Bypass. Whenever those headers appear in the origin's Vary response, Cloudflare skips caching entirely, ensuring personalized or user-specific responses are never stored or accidentally served to someone else.

Why This Matters

The most immediate benefit is improved cache efficiency. Applications serving multiple representations of the same resource—such as localized pages, optimized image formats, or compressed responses—can now keep those variations cached at Cloudflare's edge instead of repeatedly forwarding requests to the origin. As a result, users benefit from:

• Lower latency
• Faster Time to First Byte (TTFB)
• Reduced origin traffic
• Better cache utilization
• Lower infrastructure costs

Equally important is the reduction in implementation complexity. Previously, supporting variation-aware caching often required custom middleware or Cloudflare Workers to inspect request headers and generate cache keys manually. With native Vary support in Cache Rules, applications that already return a standards-compliant Vary header can benefit from intelligent cache variation without additional edge logic. This means:

• No custom cache key generation
• No additional middleware or edge scripts
• Native support through Cache Rules
• Simpler deployment and maintenance

Cloudflare's implementation also aligns with existing HTTP standards and is broadly available:

• RFC 9111 compliant: Cache key calculation follows the HTTP caching model defined in RFC 9111.
• RFC 9110 compliant: Vary:* continues to bypass caching as required by the HTTP specification.
• Available on all plans: Native Vary support is supported across Free, Pro, Business, and Enterprise plans.
• Workers integration: Workers subrequests can control cache variation programmatically using the cf.vary property.

What This Means for Developers

For years, developers had to choose between personalization and performance. Supporting multiple versions of the same URL often meant restructuring URLs, bypassing the cache entirely, or maintaining custom edge logic just to generate cache keys.

Native support for the Vary header removes much of that complexity. By bringing variation-aware caching directly into Cache Rules, Cloudflare enables standards-compliant origins to serve multiple representations of the same resource without sacrificing cache efficiency or requiring additional edge code.

As modern applications become more dynamic and personalized, intelligent caching becomes increasingly important. Native Vary support allows Cloudflare to understand not just which resource is being requested, but which representation of that resource should be served. The result is simpler application logic, more efficient cache utilization, lower origin load, and a faster, more consistent experience for users.

Sources: Cloudflare Docs – Serving tailored content with Vary , Cloudflare Docs – Cache Rules , RFC 9111 – HTTP Caching , and RFC 9110 – HTTP Semantics . The implementation details and examples are based on Cloudflare's documentation for native Vary support in Cache Rules and the HTTP caching specification.