死链检测方法：异常恢复后怎样区分缓存过期与真正修复
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /afee671bba6f.html
📄
死链检测方法：异常恢复后怎样区分缓存过期与真正修复
先看一个可核对的判据：如果同一URL在不同节点、不同请求头或不同时间返回的结果不一致，通常说明你看到的是缓存或中间层旧副本，而不是源站已经修复；只有当源站直连、绕过缓存后仍稳定返回目标状态，才更接近真正修复。下面把“缓存过期”和“真正修复”拆成两种条件，分别给出选择依据、实施动作和例外。
条件一：源站直连已变，但公开访问仍旧
这时优先怀疑缓存层和CDN边缘节点，而不是继续改源站。判断依据是：源站日志里已经出现新的响应，公开访问却仍返回旧状态；或者同一URL在带随机查询参数时结果不同。实施动作是先用curl -I直连源站，再对公开域名发起一次带随机参数的请求，比较状态码和关键响应头。如果直连正常、公开访问异常，下一步应推动缓存清理或等待TTL到期，而不是重复修改页面。例外是：如果该URL被robots.txt限制抓取，清理缓存也不会让搜索引擎重新抓取，抓取限制和索引移除是两件事。
条件二：源站直连也异常，但部分节点正常
这更可能是多节点配置不一致或发布未全量生效。判断依据是：同一时间从不同出口请求，状态码或跳转目标不同；或者部分节点返回新内容，部分节点仍指向旧地址。实施动作是记录每个节点的响应，按节点分组，而不是按“整体已恢复”下结论。如果多数节点正常、少数异常，下一步应检查发布流水线和节点同步，而不是回滚全部内容。例外是：如果异常节点只出现在特定地区或特定网络，也可能是本地DNS或代理造成，需要换网络复测后再判断。
把分歧转成可核对的项目
多个角色对“是否修复”有不同理解时，不要争论结论，先统一核对项。建议固定四项：请求目标、请求方式、观察时间、响应证据。请求目标要写清是源站IP、测试域名还是公开域名；请求方式要写清是否带缓存绕过参数；观察时间要精确到分钟；响应证据要保留状态码、跳转链和关键响应头。这样做的结果是：如果两个人结论不同，能立刻看出差异来自哪个变量，下一步只需复测那个变量，而不是重新全量检测。
一个注明假设的短例子
假设某旧文章URL返回404，修复后源站已返回301到新文章。此时公开访问仍返回404。若直连源站返回301、公开域名返回404，且带随机参数后公开域名也返回301，那么更可能是边缘缓存未过期。动作是清理该URL缓存并等待生效，然后再复测。若直连源站也返回404，则说明修复未生效，应检查重定向规则或发布状态。这个例子里，随机参数只是用来区分缓存命中与否，不是证明修复完成的唯一依据。
哪些现象不能单独证明修复
请求量、抓取量或某项统计归零，不能单独证明处理正确。它们还可能来自抓取预算转移、站点地图未更新、robots.txt限制、日志采样或统计口径变化。站点地图不保证收录，robots.txt的抓取限制也不等于可靠的索引移除。更稳妥的做法是：把源站响应、公开响应、抓取记录和索引状态分开核对，只有多项证据指向同一结论时，才把“异常恢复”升级为“真正修复”。如果不同搜索引擎支持情况不同，应分别核查，不要用一套结果推断全部。
