Vercel's CDN Stops Caching Any Response That Varies on Cookie

Vercel’s CDN stopped caching any response whose Vary header includes Cookie, so routes that relied on that cache will now miss on every request, according to a Vercel changelog entry dated Sept. 30, 2026.

What changed

The response still reaches the visitor. Vercel just no longer keeps a copy for the next one. The company said the aim is to avoid filling the cache with huge numbers of low-reuse entries, since a cookie value is usually unique to one visitor.

Other supported Vary headers behave as before.

How to tell if you’re hit

Check the x-vercel-cache response header. A MISS on a route that used to hit is the first sign. Runtime Logs show the cache reason as vary_key_denied:cookie.

The two fixes

Vercel’s guidance splits on one question: does the response actually change with the cookie?

• No. Remove Cookie from Vary, and the CDN will cache the response again.
• Yes. Keep Cookie in Vary and add Cache-Control: private, so personalized content stays out of the shared cache.

Our take

A cache keyed on a per-visitor value is a cache that almost never hits, and it costs storage to hold. The risk is the quiet kind: frameworks and middleware often set Vary: Cookie as a blanket safety default, so a team can have the header without having chosen it. Those pages now go to origin on every request, which shows up as slower responses and more function invocations, with no deploy on the team’s side to explain it.

Vercel’s changelog doesn’t say how many sites are affected, and we found no developer reaction to the change yet. Teams that serve mostly public pages should grep their own responses for the header this week.