自定义404错误页，异常恢复后怎样区分缓存过期与真正修复
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /1640992e0708.html
📄
自定义404错误页，异常恢复后怎样区分缓存过期与真正修复
先给结论：如果异常期间返回过5xx或空响应，恢复后短时间看到200和正常内容，不能直接判定修复完成。真正修复的证据是源站稳定返回预期状态码与内容，缓存过期只是让旧副本到期，源站错误可能仍在。区分方法是绕过缓存直连源站，并在多个时间点重复核对。
矛盾现象：监控显示恢复，直连源站仍异常
一个常见矛盾是：CDN或反向代理的监控面板显示正常，但开发人员用内网地址访问同一个自定义404错误页，仍拿到5xx。两个角色对“是否修好”产生分歧，不是谁在说谎，而是他们观察的对象不同——一个看的是边缘缓存副本，一个看的是源站响应。
这种分歧可以转成可核对的项目：固定请求路径、固定请求头、固定时间窗口，分别记录边缘与源站的响应状态码、响应体和响应时间。把两列数据放在一起，矛盾往往立刻显形。
两种解释：缓存自然过期，还是源站真的改了
解释一：缓存过期。异常发生时，边缘节点可能缓存了错误响应或旧版本页面。当缓存TTL到期，边缘回源重新取到正常内容，于是外部看到恢复。此时源站的代码、配置或上游依赖可能并未改动。
解释二：真正修复。源站修改了路由规则、修复了后端异常、补齐了模板变量，使自定义404错误页在任何缓存状态下都能正确返回。此时无论缓存是否过期，直连源站都应得到预期结果。
两者的外部表现可能一模一样，区别在于恢复是否依赖缓存层。
区分证据：绕过缓存后的状态码与内容一致性
能区分两种解释的证据，按可靠性排序如下：
- 直连源站的响应。用Host头指向源站IP、或走内部回源地址请求同一路径。若直连仍返回5xx或空内容，说明只是缓存过期。
- 多次回源的一致性。在十分钟、一小时、次日各取一次直连结果。真正修复应稳定；缓存过期后若源站仍有间歇错误，会在某个时间点再次暴露。
- 响应体的差异。缓存副本常带Age、X-Cache等头部，且内容可能缺少动态字段。直连响应若包含完整模板输出和正确状态码，更接近真实修复。
- 变更记录。代码提交、配置发布、上游依赖恢复的时间点，是否早于外部观察到的恢复时间。若恢复时间与TTL到期吻合而与变更时间不吻合，缓存过期的可能性更高。
注意，请求量或抓取量归零不能单独证明修复正确。它还可能来自监控采样中断、日志管道延迟、上游限流，或异常期间爬虫自然减少。需要和直连结果交叉核对。
一个假设例子：用两次直连判断下一步
假设某站的自定义404错误页在异常期间返回503，两小时后外部访问恢复正常。团队做两次直连源站请求：第一次在恢复后立即执行，返回503；第二次在次日执行，返回200且内容完整。
这个结果说明：第一次的“恢复”是缓存过期造成的假象，源站当时仍在报错；第二次直连正常，才具备真正修复的证据。下一步不应直接宣布完成，而应再检查该页面在无缓存、带查询参数、以及不同UA下的返回是否一致，确认修复覆盖了所有入口。若第二次直连仍异常，则应回到源站日志和上游依赖排查，而不是继续等待缓存刷新。
把分歧转成核对清单
当多个角色对同一事实理解不同，用以下动作收敛：
- 约定一个固定URL和一组固定请求头，作为唯一核对对象。
- 分别记录边缘响应与直连源站响应的状态码、响应体摘要、时间戳。
- 在至少两个时间点重复采集，避免单次采样误导。
- 对照变更记录，判断恢复时间更接近TTL到期还是配置发布。
- 只有直连源站稳定返回预期结果，才把状态标记为已修复；否则继续按异常处理。
如果站点还依赖站点地图或robots.txt来管理404页面的可见性，要记住：抓取限制不等于索引移除，站点地图也不保证收录。这些手段不能替代对源站响应本身的验证。
