死链检测异常恢复后怎样区分缓存过期与真正修复
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /2767649e8d59.html
📄
死链检测异常恢复后怎样区分缓存过期与真正修复
先给结论：异常恢复后，不要用“页面现在能打开”或“工具不再报错”作为修复完成的证据。真正修复的标志是源站对同一URL稳定返回预期状态，并且这个状态在绕过缓存、更换网络出口、间隔一段时间后仍然一致；缓存过期只会让旧结果消失，不会改变源站的响应逻辑。两者的分界点在于：你能否在源站侧复现这个变化，并解释它为什么发生。
先判断你看到的是哪一层的变化
死链检测通常经过多层：浏览器或本地DNS缓存、CDN或反向代理缓存、检测工具的抓取缓存、源站应用与数据库。异常恢复可能只发生在其中一层。区分方法不是反复刷新，而是逐层剥离。
- 只在一台设备或一个网络恢复：更可能是本地缓存或DNS缓存过期，源站可能仍返回旧状态。
- 换网络、换出口IP后仍正常：缓存过期的解释变弱，源站变化的可能性上升。
- 带随机查询参数请求仍正常：说明缓存键很难命中同一份副本，源站返回了新状态。
- 直接请求源站IP或回源地址仍异常：边缘缓存即使已经刷新，源站问题仍在，属于假恢复。
这里的关键动作是：用curl -I或等效方式请求目标URL，观察状态码、Age、Cache-Control、X-Cache等响应头，再对同一URL追加一个随机参数重新请求。如果带随机参数的请求返回预期状态，而不带参数的请求仍返回旧状态，说明你遇到的是缓存层尚未过期，而不是源站已经修复。这个结果直接决定下一步：应该去刷新缓存或等待TTL，而不是继续改源站代码。
条件一：源站已改动，缓存还没过期
这种情况下，源站对回源请求已经返回正确状态，但边缘节点仍在TTL内提供旧响应。判断依据是回源请求与边缘请求结果不一致，且响应头显示缓存命中。
此时合理的做法是主动清理相关URL的缓存，或等待TTL自然过期。清理后要重新做一次不带随机参数的请求，确认边缘节点返回的是新状态。代价是：如果只清了缓存却没有确认源站逻辑，下一次回源可能又把错误状态重新缓存一遍，异常会再次出现。所以清理缓存这个动作的结果，必须用回源验证来闭环，否则你只是把问题推迟了一个TTL周期。
条件二：源站未改动，只是缓存过期
如果源站从未修复，只是旧缓存到期后重新回源，而源站此时恰好返回了正常状态，这属于偶然恢复。它的特征是：同一URL在短时间内多次请求结果不稳定，或者换个时间点又变回异常。
判断方法是做时间序列观察，而不是单次检测。在较长窗口内对同一URL重复请求，记录每次的状态码和回源标记。如果结果在正常与异常之间摆动，说明源站存在间歇性故障，缓存过期只是让你看到了其中一个瞬间。
这种情况下不应该把任务标记为完成。应该继续排查源站的应用日志、数据库连接、上游依赖，找出间歇性的触发条件。代价是排查周期更长，但比反复“修复—复发”要省事。
用一个假设例子说明比较方法
假设某分类页在死链检测中报404，运维清理了CDN缓存后页面恢复200。此时有两种解释：一是源站内容确实被修复，缓存只是旧的；二是源站本来就间歇性返回200，缓存过期让你碰上了正常的一次。
区分这两者的动作是：连续多天、每天多个时间点请求该URL，同时记录是否命中缓存。如果带随机参数的回源请求始终返回200，且应用日志中没有对应的异常记录，支持第一种解释；如果回源请求时而200时而404，支持第二种解释。这个例子的数字仅用于说明比较方法，不代表任何真实站点的表现。
例外：状态码正常不等于修复完成
有些恢复是状态码层面的，但页面内容仍然是错误页、空页或跳转到无关地址。死链检测如果只看状态码，会把这类情况误判为已修复。
因此验证时要同时检查：返回的正文是否包含预期内容、是否被重定向到不相关URL、页面标题与目标主题是否一致。如果状态码是200但正文是“页面不存在”的软404，那仍然是异常，只是换了一种表现形式。
另外，robots.txt的抓取限制不等于可靠的索引移除，站点地图也不保证收录。即使页面已经恢复200，也不代表它会被重新抓取和重新索引。这两件事需要分开验证，不能因为检测工具不再报错就认为整个链路已经恢复。
把判断固化成可复查的步骤
- 对同一URL分别做边缘请求和回源请求，记录状态码与缓存相关响应头。
- 对同一URL追加随机参数请求，判断缓存键是否影响结果。
- 在多个时间点重复上述请求，观察结果是否稳定。
- 检查正文内容，排除软404和错误跳转。
- 只有源站回源稳定返回预期状态且内容正确时，才把该URL标记为真正修复。
如果第1步显示边缘与回源不一致，下一步是处理缓存；如果第3步显示结果不稳定，下一步是排查源站间歇性故障；如果第4步显示内容不对，下一步是回到内容或路由配置。每一步的结果决定下一步动作，而不是把所有恢复都当成同一类问题处理。真正修复意味着你能解释变化发生的原因，并且这个解释在复查时仍然成立。
