同一个站点里，有些页面能命中 CDN，有些页面却每次都回源；控制台还显示部分请求被跳过缓存。这个现象通常不是 CDN 随机失效，而是响应头、Cookie、请求方法或路径规则让不同请求进入了不同的缓存处理流程。
排查时要先确认哪些响应本来就不应共享缓存，再判断哪些公开内容被错误地排除了。不要为了提高命中率，直接删除 Set-Cookie 或忽略登录相关的 Cookie。共享缓存配置错误可能造成用户数据串用。
先把“未缓存”分成几类
同一个“MISS”或“BYPASS”状态，可能代表缓存对象不存在、响应明确禁止存储、请求带有不允许缓存的 Cookie，或者当前路径规则配置为直接回源。先记录 CDN 返回的缓存状态及服务商定义，再与源站响应头对照。
选择一个公开、无登录态的小型 HTML 或 JSON 响应，分别保存：
请求方法、完整 URL 和查询参数；
Cache-Control、Expires、Age、ETag与Vary；是否返回
Set-Cookie；CDN 的缓存状态、规则名称和请求追踪 ID；
两次请求的正文摘要与源站访问记录。
不要把带有真实会话 Cookie 的响应复制到公共环境。测试时使用专门的公开对象，并清楚记录请求是否经过浏览器、Service Worker 或其他代理。
Cache-Control 决定了很多默认行为
Cache-Control: no-store 表示响应不应被存储；no-cache 表示复用前需要重新验证，并不等同于完全禁止存储；private 表示响应面向单个用户，不适合共享缓存。不同 CDN 对这些指令的覆盖方式不同，最终还要结合缓存规则核对。
如果源站框架对所有 HTML 都统一添加 private 或 no-store，公开页面就可能全部绕过 CDN。反过来，如果为了提高命中率在边缘强行忽略这些指令，登录页面、购物车和个性化 API 可能进入共享缓存。
先按内容类型拆开检查：公开静态资源、公开 HTML、个性化 HTML、API 和下载响应通常不应使用同一套策略。对每一类明确允许缓存的条件、缓存时间和失效方式。
Set-Cookie 会让公开页面退出共享缓存
响应中出现 Set-Cookie，常常意味着源站正在建立或更新会话。很多 CDN 会因此跳过缓存，或者把响应视为不适合共享。即使页面内容本身完全公开，也不要直接删除这个头来换取命中率。
检查应用是否在每次请求都设置无关紧要的追踪 Cookie、AB 实验 Cookie 或空会话 Cookie。如果确实需要 Cookie，先确认它是否影响正文；不影响正文的状态可以考虑由应用改为更明确的客户端处理，但应先在测试环境验证。
对登录态、权限和购物车响应，保持共享缓存隔离。对完全公开的资源，使用独立域名、版本化文件名和明确的缓存头，通常比依赖边缘“猜测”更容易维护。
请求头和缓存键会制造看不见的分支
Vary 以及 CDN 自定义缓存键可能让 Accept-Language、Accept-Encoding、设备标识或某些 Cookie 参与对象区分。分支越多，缓存对象越分散，命中率就越低；如果忽略了真正影响内容的请求头，又可能把不同版本混在一起。
对异常请求比较以下项目：
Accept-Encoding是否导致 gzip、Brotli 和未压缩版本分开；Accept-Language是否生成过多语言对象；Cookie 和自定义请求头是否真的改变响应正文；
查询参数是否被全部纳入缓存键；
CDN 规则是否在不同路径上覆盖了源站的缓存头。
不要为了减少对象数量，盲目移除与权限、租户或语言有关的变化项。先确认业务语义，再决定是否可以归一化。
受控请求验证实际规则
下面的命令只读取公开测试 URL，分别请求普通模式和带压缩声明的模式。请替换域名与路径，不要使用真实登录 Cookie。
curl -sS --max-time 10 \ -D response-1.headers -o response-1.body \ 'https://cdn.example.com/public/test.html' curl -sS --max-time 10 \ -H 'Accept-Encoding: gzip, br' \ -D response-2.headers -o response-2.body \ 'https://cdn.example.com/public/test.html'
记录 Cache-Control、Vary、Set-Cookie、Age 和 CDN 缓存状态。两次响应的状态不同，不一定说明缓存错误，可能只是缓存键或编码变体不同。若要比较正文，先按 Content-Encoding 正确解码，再计算摘要。
修复顺序要从风险最高处开始
先确认登录、权限、购物车和用户 API 没有进入共享缓存；再处理公开页面和静态资源的命中率。对公开内容，优先改正源站响应头、减少无意义 Cookie、使用版本化 URL，并为不同内容类型设置独立规则。
每次只改一个路径组或一个缓存条件，保存原配置和回滚方法。验证时同时观察正文内容、缓存状态、源站请求量、错误率和响应延迟。不要用全站清缓存掩盖规则问题，也不要在生产环境通过随机查询参数持续制造回源。
最终要能说明：哪些响应允许共享缓存，哪些响应必须回源；命中率下降是规则导致的，还是请求变体过多；修复后是否仍存在用户数据串用风险。缓存数字本身不是验收标准，内容隔离和可重复验证才是。
参考资料
资料核验日期：2026 年 11 月 11 日。本文命令为受控读取示例，不代表已在读者的生产环境执行。
