📍 WDQWDWQD987AAAAA:216.73.216.246
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /6f179686d6d4.html
📄

网站缓存怎样识别配置互相冲突：从响应头与命中行为判断

识别网站缓存配置冲突，核心是看同一份资源是否被不同层给出了互相矛盾的缓存指令。浏览器缓存、CDN 缓存、反向代理缓存和源站响应头若各自为政，就会出现“有的用户看到旧页面、有的看到新页面”或“刷新多次结果不一致”。判断方法不是猜，而是逐层核对响应头与命中状态。

一个假设例子：同一张图片出现两种缓存时长

假设某站点在源站 Nginx 里对图片设置了 Cache-Control: max-age=86400，同时在 CDN 控制台把图片目录的缓存过期时间设为 10 分钟。用户第一次访问时，CDN 未命中，回源拿到 24 小时指令并缓存；10 分钟后 CDN 认为过期，再次回源。此时浏览器仍按 24 小时保存旧副本，于是出现“服务器已更新、部分用户仍看到旧图”。

这个例子里冲突点有两个：一是 CDN 与源站的过期时间不一致，二是浏览器缓存时长大于 CDN。排查时先固定一个资源 URL，用浏览器开发者工具的 Network 面板查看 Cache-Control、Age、ETag 和状态码，再与 CDN 回源日志对照，就能定位是哪一层在“自作主张”。

检查项：哪些信号说明配置可能打架

• 同一 URL 多次请求返回的 Cache-Control 不一致，说明中间层改写了响应头。
• Age 值忽大忽小或始终为 0，可能表示 CDN 命中不稳定或未按预期缓存。
• 源站返回 no-cache 或 private，但 CDN 仍缓存了该资源，属于典型冲突。
• 页面 HTML 被缓存，而其中的接口数据实时变化，导致页面结构与数据版本不匹配。
• 设置了 Vary 头但 CDN 未按该维度区分缓存，可能把移动端和桌面端内容混用。

这些现象只能说明“可能存在冲突”，不能单凭一项就断定原因。比如 Age 为 0 也可能只是刚回源，需要连续观察多次请求再判断。

两种处理方案的比较与适用条件

方案一：统一由源站下发缓存指令，CDN 与反向代理遵循源站。适用条件是团队能集中管理响应头，且各层支持透传。优点是规则单一、不易矛盾；缺点是源站配置失误会同时影响所有层。

方案二：在 CDN 层覆盖源站指令，按路径或文件类型单独设置。适用条件是源站不便改动，或需要对静态资源做更激进的缓存。优点是灵活；缺点是覆盖规则与源站规则容易脱节，必须定期核对。

选择依据是：如果资源更新频率低且团队规模小，方案一更省心；如果静态资源量大、源站由多个系统拼装，方案二更现实，但要把覆盖规则记录成清单，每次改源站时同步检查。

可执行步骤：逐层核对并记录结果

1. 选一个具体资源 URL，分别用直连源站和经过 CDN 的方式请求，保存两次响应头。
2. 对比 Cache-Control、Expires、ETag、Last-Modified 是否一致。
3. 在 CDN 后台查看该 URL 的缓存状态与命中次数，确认是否按预期缓存。
4. 若涉及 HTML，检查是否被错误缓存；必要时对 HTML 使用较短缓存或协商缓存。
5. 把核对结果写成表：资源类型、源站指令、CDN 指令、实际命中行为、结论。

常见错误是只看浏览器刷新结果就下结论。浏览器强制刷新会绕过本地缓存，不能代表普通用户的命中路径。另一个错误是把 robots.txt 的抓取限制当成缓存控制手段，它既不等于可靠的索引移除，也不影响 CDN 是否缓存资源。

判断结果与下一步

如果直连源站与经过 CDN 的响应头一致，且命中行为符合预期，说明当前没有明显冲突；如果响应头被改写或命中行为与规则不符，就按上表定位到具体层再调整。调整后不要只测一次，应在缓存过期前后各测一轮。下一步是把你站点上最常更新的三类资源列出来，逐一执行上面的核对步骤，先解决影响面最大的那一类。