一个 Set-Cookie 就能让整站不可缓存
多数 CDN 看到响应带 Set-Cookie 就判定不可缓存。框架默认的会话中间件常常给静态资源也带上它。
5 分钟协议与压缩
要点
如果命中率异常低且缓存状态是 BYPASS 或 DYNAMIC，先检查响应里有没有 Set-Cookie——这是最常见的单一原因。
CDN 为什么拒绝缓存
Set-Cookie 意味着这个响应包含针对特定用户的状态。如果 CDN 把它缓存下来发给别人，就会把一个用户的会话标识发给另一个用户——这是严重的安全问题。所以 CDN 的默认行为是保守地不缓存。
# 一个本该被缓存一年的静态资源
GET /assets/app.7f3a91c2.js
HTTP/1.1 200 OK
Cache-Control: public, max-age=31536000
Set-Cookie: session=abc123; Path=/ # ← 这一行让上面那行失效它是怎么混进静态资源的
- 会话中间件挂在全局，对所有路径生效，包括静态资源路径；
- 框架的默认配置会为每个请求初始化会话，即使这个请求不需要；
- 分析或 A/B 测试的服务端组件给所有响应打标；
- 反向代理层统一注入 Cookie。
最容易搞错的一点
很多人会去 CDN 侧配置「忽略 Set-Cookie 强行缓存」。这能让命中率数字变好，但如果那个 Cookie 真的是会话标识，你就制造了一个跨用户泄露会话的漏洞。正确做法是在源站侧不要对静态资源下发 Cookie。
修复顺序
- 先用实测工具确认哪些路径的响应带了 Set-Cookie；
- 把会话中间件的作用范围限制到真正需要的路由，排除静态资源目录；
- 如果静态资源由独立域名或独立服务提供，问题天然不存在——这也是使用独立静态域名的理由之一；
- 修完再看缓存状态是否从 BYPASS 变成 HIT。
在你的网站验证
边缘核验检查哪些响应意外带上了 Set-Cookie