网站死链：异常恢复后怎样区分缓存过期与真正修复
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /85636da7d632.html
📄
网站死链：异常恢复后怎样区分缓存过期与真正修复
直接判断方法：把“同一请求在不同节点、不同身份、不同时间”的结果分开看。若只有带缓存的节点返回正常、源站直连仍异常，多半是缓存过期；若源站直连、无缓存请求和外部探测都稳定正常，才接近真正修复。异常恢复后最危险的动作，是看到一次200就批量撤掉监控和跳转。
两种条件决定你该信缓存还是信修复
条件一：你只能通过CDN或反向代理观察结果，无法直连源站。此时任何“恢复”都先按缓存过期处理，因为边缘节点可能保留了旧的404，也可能刚换上新缓存，两者外观相同。
条件二：你能直连源站，并能指定不带缓存头的请求。此时才具备区分资格。做法是分别记录源站响应、边缘响应和带随机查询串的响应，三者一致正常，才进入“疑似修复”阶段。
选择依据不是响应码本身，而是响应码的来源。一次200可能来自缓存副本、错误页软404、跳转链末端，也可能是真实内容回归。把来源标出来，比争论“是不是修好了”更有用。
实施动作：用一组对照请求替代单点验证
先固定一个样本URL，不要同时换十个。对同一个URL发起三类请求：直连源站、经缓存节点、附加随机查询串绕过缓存。记录状态码、响应体首段特征、最终URL和响应时间。
- 直连源站异常、缓存节点正常：判定为缓存过期，继续观察，不动监控。
- 直连源站正常、缓存节点异常：判定为缓存未刷新，执行刷新或等待过期，仍不动监控。
- 三者都正常，且响应体是目标内容而非通用错误页：进入下一轮，扩大样本。
这个动作的结果直接决定下一步：只有第三种情况才值得扩大样本。若在第一种情况下就批量恢复内链和提交，等于把缓存假象当成修复依据，后续异常会再次出现，而你已经失去了对照样本。
规模化后出现例外：样本成立不等于全站成立
个别URL通过三类请求验证正常后，常见例外有三类。第一类是模板差异：同一批死链里，列表页和详情页的恢复机制不同，详情页正常不代表列表页正常。第二类是参数差异：带参数的旧URL可能仍返回404，而无参数版本已恢复。第三类是区域差异：不同缓存节点过期时间不一致，你测到的节点正常，其他节点仍在返回旧结果。
因此规模化验证必须保留分层样本：按模板、按参数形态、按节点各留几个。若某一层持续异常，说明修复只覆盖了部分路径，不能对外宣布整体恢复。
假设例子：某站点有100条死链，抽10条直连源站均返回200，于是全部撤掉跳转。一周后其中带查询参数的30条再次404，因为源站只修复了无参数路径。这个例子里，错误不在抽样数量，而在样本没有覆盖参数形态这一层。
哪些现象不能单独证明修复完成
抓取量回升、日志里404减少、站点地图重新提交后出现访问，这些都不能单独证明死链已修复。抓取量回升可能只是爬虫重访旧URL；404减少可能是日志轮转或采样变化；站点地图被访问也不保证收录。它们可以作为辅助信号，但必须和源站直连结果对照。
另外要区分抓取限制与索引移除：robots.txt 禁止抓取不等于页面已从索引移除，也不等于死链已处理。若你用robots.txt挡住异常URL来“让问题消失”，那只是把可见性关掉，源站状态没变。HTTPS同样不保证页面可访问或内容正确，它只说明传输层加密，和死链修复无关。
决定撤掉监控前的最小条件
撤掉监控或跳转前，至少满足：源站直连正常、缓存节点正常、绕缓存请求正常，且分层样本在约定观察期内保持稳定。观察期长度按你站点的缓存过期策略设定，不设统一数字。
如果只能满足其中一两个条件，保留监控和跳转更稳妥。跳转本身不是修复，但它能避免用户在异常期间看到404；等三类请求都稳定后，再决定是否移除跳转并恢复原始URL。这个顺序能让你在下一次异常出现时，仍有可对照的基线。
