死链接修复方法：访问量突增时先分清资源压力还是配置错误
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /e4fec5c07978.html
📄
死链接修复方法：访问量突增时先分清资源压力还是配置错误
访问量突增时出现大量404或跳转异常，先不要急着批量改规则。更稳的做法是取一个当前报错的URL，分别核对它是否只在高峰失败、是否所有客户端都失败、以及响应是来自应用还是边缘层。若低峰正常、高峰失败且响应时间同步上升，更像资源压力；若低峰也失败、不同网络结果不同、或返回固定错误页，则更像配置错误。两者处理顺序不同，先定性再动手。
先固定一个可核对的样本URL
把问题从“很多人说打不开”转成一个具体对象：选一条昨天还正常、今天报错的死链，记录它的完整路径、请求方法、期望状态码和实际状态码。同一路径至少测三次：低峰一次、高峰一次、换一个网络出口一次。
记录时只保留可复核字段：时间、客户端类型、返回状态、响应体前几行、是否命中跳转。不要先写结论，先把三次结果并排放。若三次结果不一致，说明问题可能随时间或路径变化，而不是一条静态规则写错。
用三个证据区分压力与配置
压力与配置都会表现为404、502或跳转循环，但证据分布不同。可以按下面三项判断：
- 时间相关性：只在高峰失败、低峰恢复，且失败率与响应时间同步上升，倾向资源压力。若低峰也稳定失败，倾向配置错误。
- 一致性：所有客户端、所有网络都返回同一错误页，倾向配置错误；只有部分客户端超时或连接被重置，倾向资源压力或中间层限流。
- 错误来源：响应头或错误页由应用框架生成，说明请求已到达应用；若在边缘层就被改写或直接返回，说明规则或路由先于应用生效。
注意，请求量归零或抓取量下降不能单独证明配置正确。它也可能是采集端主动降频、缓存命中变化或监控口径改变。需要结合同一样本URL在多个时间点的结果一起看。
把分歧转成一张可执行核对表
多个角色对同一事实有不同理解时，不要争论“是不是配置问题”，而是把分歧写成可核对的条目。例如运维认为应用已恢复，SEO认为搜索端仍看到404，编辑认为页面还在。此时以同一条URL为对象，分别核对：
- 应用日志中该路径最近一次返回的状态码和时间。
- 边缘层或反向代理是否对该路径做了重写、跳转或拦截。
- 页面在站内链接、站点地图、历史外链中分别指向哪个地址。
- 搜索结果中展示的地址是否与当前可访问地址一致。
这张表的作用不是立刻修复，而是确定下一步动作。若应用日志显示200而边缘层显示404，下一步应检查路由与重写顺序；若应用日志本身显示404，下一步才回到内容或链接层处理。
假设例子：一次高峰后的404激增
假设某站点在活动期间访问量上升，监控显示404数量同步增加。取一条样本URL /old-page 核对：低峰访问返回301到新地址，高峰访问返回502，换网络后仍为502。此时不能直接判定为死链修复失败，因为低峰跳转是正常的，高峰失败更可能来自上游超时或连接池耗尽。
下一步动作应是先确认该路径是否仍被旧链接大量请求，再检查高峰时段应用与边缘层的错误分布。若确认是资源压力，处理顺序是先限流或扩容，再回头验证跳转是否恢复；若在低峰也返回404，才进入规则和链接替换流程。这个顺序能避免在压力期误改跳转规则，把可恢复的问题变成真正的死链。
修复动作与结果如何影响下一步
确定性质后，动作要有明确的验证对象。若是配置错误，修改一条规则后，用同一样本URL在低峰和高峰各测一次，并核对返回状态、跳转目标和响应体。若两次一致且符合预期，再扩大到同类路径；若仍不一致，说明还有第二层规则或缓存未更新。
若是资源压力，先处理容量或限流，再观察同一URL的失败率是否随响应时间下降而下降。若失败率不降，说明压力不是唯一原因，需要回到配置层继续核对。无论哪种情况，都不要用“抓取量下降”或“请求量归零”作为唯一成功标准，因为它们可能来自采集端变化，而不是修复生效。
最后，把这次核对用的样本URL、三次结果、采取的动作和下一次验证时间留在同一处。这样下次再出现类似分歧时，可以直接从上次的核对表继续，而不是重新争论问题属于哪一类。
