CDN 上线后命中率下降，团队常会先怀疑节点故障或供应商问题。但缓存是一个由 URL、请求头、响应头、源站状态和业务版本共同决定的结果。只比较一个总命中率，很难知道问题发生在哪一层。
先确认你看的是哪种命中率
请求命中率和字节命中率不是同一个指标。一个小接口可能请求量很大但字节很少；图片和下载则可能请求量不大却占总流量的绝大部分。至少要分别查看请求数、流量体积和关键业务路径，避免用平均值掩盖局部异常。
| 指标 | 用途 | 容易误判的地方 |
|---|---|---|
| 请求命中率 | 观察缓存覆盖的请求比例 | 大量小请求会放大比例变化 |
| 字节命中率 | 观察回源流量节省 | 图片下载可能掩盖接口全部回源 |
| 路径命中率 | 定位具体资源 | 全站总比例可能掩盖单路径归零 |
| 状态码分布 | 区分成功缓存和错误响应 | 缓存 404/5xx 不代表业务正常 |
第一个变量：缓存键是否改变
缓存键通常包含主机名、路径和部分查询参数。版本发布后新增了查询参数、Cookie、设备判断或语言参数，都会产生新的缓存对象。先对同一个 URL 和同一个请求头组合比较变更前后的缓存状态，再扩大到路径和参数矩阵。
第二个变量：源站状态码是否变化
源站从 200 变成 403、404、429 或 500 时，CDN 可能按策略不缓存，也可能缓存错误。分别统计边缘状态码和回源状态码，确认回源失败是否与命中率下降同时发生。
第三个变量：Cache-Control 和 Vary 是否改变
发布、插件更新或源站安全策略可能改变 Cache-Control、Set-Cookie、Vary 和过期时间。检查变更前后的响应头，避免只比较 CDN 控制台规则而忽略源站返回。
第四个变量：文件版本和发布方式
文件名、目录或构建哈希变化会产生一批新的缓存对象。上线瞬间命中率下降可能是正常冷启动，关键是看命中率是否在预期时间内恢复，以及新版本是否存在额外的回源失败。
第五个变量：参数、Cookie 和登录状态
带随机参数的链接、跨站跟踪参数、用户 Cookie 和登录判断都会降低共享缓存利用率。不要为了提升数字而缓存用户相关页面；这类页面命中率较低可能正是正确设计。
一次可执行的定位顺序
- 选一个受影响 URL，保存完整请求头与响应头。
- 对比变更前后缓存键和
Cache-Control。 - 同时记录边缘状态码、回源状态码和响应时间。
- 按静态资源、公开页面、API、登录页分别统计。
- 确认是否只是新版本冷缓存，再决定调整规则。
边界：命中率不是越高越好。登录、支付、购物车和用户接口命中率很低可能是合理的安全与一致性设计。优化目标应是回源成本和业务正确性同时成立。
延伸阅读：CDN 缓存边界怎么划 · CDN 回源验证 · 带宽与月流量计算器。