网站已经接入 CDN，源站请求量却突然升高。很多时候不是 CDN 没有工作，而是同一份内容被拆成大量不同的缓存对象，导致边缘节点不断回源。

先确认问题发生在哪一层

先查看缓存命中率、回源请求数和回源流量的变化时间。连续请求同一个文件，观察 Age、Cache-Status、CF-Cache-Status、X-Cache 等响应头。不同厂商字段并不统一，应结合平台文档判断。

查询参数是否制造了大量缓存副本

utm_source、fbclid 等追踪参数即使不改变页面内容，也可能创建独立缓存对象。会改变内容的参数必须保留，只用于统计的参数可以忽略或移除。不要直接忽略全部参数，否则可能把不同页面错误地缓存成同一份内容。

Cookie 是否让公共页面无法共享缓存

统计插件、弹窗工具或 A/B 测试可能为每个访客写入不同 Cookie。如果完整 Cookie 进入缓存键，公共页面就难以复用缓存。公开页面只应让真正影响内容的 Cookie 参与缓存；登录态、购物车和个性化页面应绕过共享缓存。

Vary 是否把缓存切得过细

Vary: Accept-Encoding 通常用于区分压缩格式，但 Vary: User-Agent 可能按大量浏览器标识拆分缓存，Vary: * 通常表示响应不适合常规共享缓存。需要区分设备时，应使用数量有限的设备类别，而不是完整 User-Agent。

Authorization、缓存控制和 TTL

带 Authorization 的请求通常涉及身份信息，不要为了命中率强行缓存受保护响应。若 Cache-Control 出现 private、no-store、很短的 max-age，或者边缘 TTL 过低，缓存对象会频繁过期。

推荐的修复顺序

先锁定异常路径，再比较正常与异常请求的 URL、Cookie 和请求头。确认响应具备缓存资格后，逐项检查查询参数、Cookie、Vary 和 TTL。只有确认某个维度不会改变内容，才能将其从缓存键排除。

修改规则后优先刷新受影响的目录或 URL。用固定测试地址连续请求，确认第二次请求命中，同时检查语言、登录状态、设备和关键参数是否仍返回正确内容。

长期应监控命中率、回源请求数、回源带宽及 4xx/5xx 比例。缓存命中率不是越高越好；目标是让可共享内容稳定命中，同时保证不该共享的数据绝不进入公共缓存。