Vercel CDN no longer caches responses that vary by Cookie

What changed

Vercel has changed how its CDN treats responses whose Vary header includes Cookie. According to a changelog entry on the Vercel blog, the CDN no longer stores such responses at the edge. Requests are still served normally — the origin response passes through unchanged — but nothing is retained for later requests, so every subsequent hit effectively becomes a cache miss.

Why Cookie got singled out

The Vary header tells a cache which request headers can change the response, so the cache knows to keep separate entries for each distinct header value. Cookie is a troublesome case here: cookies often carry values unique to a single visitor, such as session identifiers. Varying on Cookie can therefore fragment a cache into a huge number of entries that are written once and almost never reused. Vercel frames this as a high-cardinality caching problem, and the new rule is its way of avoiding it. Caching behavior for the other Vary headers Vercel supports is unchanged.

How to tell whether you are affected

Vercel points to two signals. The x-vercel-cache response header on affected routes will read MISS where a HIT might previously have appeared. Runtime Logs offer a more specific clue: the cache reason will show vary_key_denied:cookie. If that reason shows up on a route you expected to be cached, the next step is to inspect the Vary header your origin returns.

What Vercel recommends

The guidance splits into two cases.

If the response is identical no matter which cookies the visitor sends, remove Cookie from Vary. Once it is gone, the response becomes eligible for CDN caching again, provided it also meets Vercel's other caching requirements.

If the response genuinely depends on cookies — personalized pages, logged-in views, per-visitor experiments — keep Cookie in Vary and mark the response with Cache-Control: private. That explicitly tells the shared CDN cache not to store visitor-specific content, which is a more accurate description of what these responses are.

Why it matters

The failure mode here is silent. Nothing breaks and no errors surface; the origin simply does more work than it used to while cache hit rates quietly slide. For routes where the origin is expensive — server-rendered pages, compute-heavy API handlers, upstream services with rate limits — the extra origin traffic can translate directly into added latency and cost.

The change also nudges teams toward better caching hygiene. Vary: Cookie is often set incidentally or copied over from another layer of the stack, without anyone weighing the cache implications. Vercel now forces an explicit decision per route: either the response is cookie-independent and should not vary on Cookie at all, or it is personalized and should not sit in a shared cache in the first place. Either answer is an improvement; the ambiguity is what produced the waste.

If you run workloads on Vercel, it is worth checking x-vercel-cache values and searching Runtime Logs for vary_key_denied:cookie before the symptoms start showing up in your metrics.