404错误页面优化，多层缓存返回不同版本时怎样定位一致性问题
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /05b126a50e98.html
📄
404错误页面优化，多层缓存返回不同版本时怎样定位一致性问题
先给有条件的结论：如果同一批失效链接在不同网络、不同设备或不同登录状态下，返回的 404 页面内容不一致，优先怀疑缓存层而非页面模板本身。成立条件是各层缓存对状态码、Vary 头和缓存键的处理不同；反例是源站本身按用户代理或地区动态输出不同 404 内容，此时清缓存不会让版本收敛。下一步动作是固定一个失效 URL，逐层旁路缓存抓取响应，记录状态码和正文指纹，再决定改缓存键、改源站输出还是改页面模板。
先区分“内容不一致”和“状态码不一致”
多层缓存场景下，不一致通常分两类。第一类是状态码一致但正文不同，例如 CDN 边缘节点返回通用 404，回源后返回带推荐链接的 404。第二类是状态码本身不同，例如边缘缓存返回 200 的软 404，回源返回 404。两类问题的排查顺序不同：状态码不一致要先查缓存是否把错误页当正常页缓存，正文不一致要先查缓存键和 Vary 头是否覆盖了区分维度。
判定依据可以看响应头中的缓存命中标识、Age 值、Vary 字段和缓存键相关头。如果同一 URL 在两次请求中 Age 差异很大，但正文指纹相同，说明缓存分层存在但内容已收敛；如果正文指纹不同且 Age 都大于零，说明至少两层各自缓存了不同版本。
用固定失效 URL 做逐层旁路，而不是随机点链接
随机抽样会把路径差异、参数差异和缓存差异混在一起。更有效的做法是选一个已知失效 URL，保持路径、查询参数、请求头和客户端环境不变，只改变缓存旁路层级。可以按下面顺序记录：
- 直连源站或绕过 CDN：记录状态码、正文指纹、关键响应头。
- 只经过第一层缓存：记录同样字段，与直连结果对比。
- 经过完整链路：再记录一次，确认差异出现在哪一层之后。
这里的正文指纹不需要复杂工具，取 404 页面中一段稳定文本的哈希即可。假设源站返回的 404 含“继续浏览”模块，边缘缓存返回的 404 不含该模块，那么差异出现在边缘缓存生成或缓存键选择环节，而不是源站模板。这个例子只用于说明比较方法，不代表任何真实项目结果。
检查缓存键、Vary 头和错误页缓存策略
多层缓存返回不同版本，常见原因是缓存键没有包含实际影响输出的维度。例如源站根据 Accept-Language 输出不同语言的 404，但缓存键只按 URL 计算，边缘就会把一种语言版本发给所有用户。此时应检查 Vary 是否包含 Accept-Language，以及各层缓存是否都尊重该字段。若只有部分层尊重，仍会出现版本漂移。
另一个原因是错误页被当作可缓存成功响应。部分缓存默认只缓存 200，部分缓存会缓存 404，还有部分缓存会把源站返回的 200 软 404 长期保存。需要确认各层对 404、410、301、302 的缓存规则是否一致。若边缘缓存 404 的时间长于源站修复时间，即使源站已恢复，边缘仍会继续返回旧 404。
实际动作：先临时缩短错误页缓存时间，再重复逐层旁路测试。如果版本开始收敛，说明问题在缓存时长和缓存键；如果仍不收敛，说明源站输出本身不稳定，应转向源站日志和动态渲染逻辑。
什么情况下不该继续清缓存
反例是源站按用户代理、登录态、地区或 A/B 实验动态输出 404 内容。此时多层缓存返回不同版本是预期行为，继续清缓存只会短暂掩盖差异。判断线索是：同一层缓存、同一 URL，在改变请求头后源站直连结果也不同。若直连源站都返回多个版本，就不应把问题归因于缓存，而应统一 404 输出策略，或明确哪些维度允许差异化。
还有一种情况是软 404：页面内容像错误页，但状态码是 200。多层缓存可能把软 404 当正常页缓存，导致后续修复无法及时生效。此时要先让源站对失效 URL 返回明确的 404 或 410，再处理缓存。robots.txt 的抓取限制不等于可靠的索引移除，站点地图也不保证收录，这两点不能替代状态码和缓存策略的修正。
下一步：把定位结果转成可验证的修改
完成逐层记录后，按差异出现的位置决定动作。若差异从第一层缓存开始，修改该层缓存键或 Vary 配置，再重复同一失效 URL 的旁路测试，确认正文指纹收敛。若差异只在完整链路出现，检查中间层是否覆盖了上游缓存头。若直连源站就有多个版本，先统一源站 404 模板和状态码，再回到缓存层验证。
每次修改后只改变一个变量，并保留修改前的响应头和正文指纹。这样下一次出现不一致时，可以判断是新缓存键引入的问题，还是源站策略再次变化。若使用 HTTPS，也不应把 HTTPS 当作安全无漏洞或排名保证，它只说明传输层加密，与 404 版本一致性无关。不同搜索引擎对 404、410 和软 404 的支持情况须分别核查，不能假设所有引擎处理方式相同。
