死链接修复方法：源站正常而边缘节点异常时应保留哪些证据
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /ab91d086cd0b.html
📄
死链接修复方法：源站正常而边缘节点异常时应保留哪些证据
当源站返回正常、边缘节点却对同一路径返回404或410时，先不要改链接，也不要立刻在源站加跳转。此时最该保留的是能证明“差异发生在哪一层”的证据：同一时刻、同一路径、不同出口的响应状态、响应头、DNS解析结果和节点标识。只有这些证据能区分两种解释——边缘缓存里存着旧响应，还是边缘配置把该路径判成了不存在。前者通常只需刷新或等待缓存过期，后者要改配置或回源规则，动作完全不同。
先区分两种解释：缓存旧响应与配置误判
两种解释在表面上都表现为“源站正常、边缘404”，但成因不同。缓存旧响应意味着边缘节点曾抓取过该路径的404或410，并把它按缓存策略存了下来；源站后来恢复或新增了该路径，边缘却仍在用旧副本应答。配置误判则是边缘规则、回源路径重写或路由表把请求导向了错误位置，源站根本没收到这次请求，或者收到的路径已经变了。
区分它们的关键证据是回源日志与边缘响应的对应关系。如果边缘404的时间点与源站访问日志中的一次404抓取吻合，且之后源站再没收到该路径的请求，缓存旧响应的解释更成立。如果边缘404的同时源站访问日志里出现了一条路径被改写后的请求，或完全没有对应请求，配置误判的解释更成立。这一步决定了下一步是清缓存还是查规则，不能跳过。
同一时刻采集多出口响应，避免时序错位
很多人核对时先在自己浏览器看到404，再去源站看是200，就断定边缘异常。但两次请求可能相隔几分钟，源站可能在这期间刚好恢复，或边缘刚好过期。要减少这种时序干扰，应在尽量短的窗口内，从不同出口对同一完整URL发起请求，并记录每一条的状态码、响应头中的缓存相关字段、时间戳和出口标识。
需要保留的字段包括：HTTP状态码、Date、Age、Cache-Control、Via或等价的节点标识头、X-Cache一类命中标记（若存在）。这些字段能说明响应是来自缓存还是回源、缓存了多久。若边缘响应带Age且数值较大，缓存旧响应的可能性上升；若没有缓存命中标记且状态仍异常，配置层面的问题更值得先查。采集动作本身要可复查：保留原始响应头文本和时间，而不是只记一句“我这边是404”。
用对照路径判断是个例还是规则性问题
单一路径异常不足以判断范围。选几条对照路径：一条同目录下正常存在的页面、一条确实已删除的页面、一条最近新增的页面。分别从边缘和源站请求，比较状态码组合。
- 只有目标路径异常，同目录正常页面在边缘也是200：更可能是该路径的缓存副本或单条规则问题。
- 同目录多条路径在边缘都异常，源站都正常：更可能是目录级规则、回源路径重写或路由配置问题。
- 新增页面在边缘异常、老页面正常：更可能是边缘尚未更新或抓取未覆盖，而非删除类配置。
- 已删除页面在源站和边缘都返回410：这是预期结果，不应计入异常。
对照结果会直接改变下一步。若指向单条缓存副本，刷新该路径并观察后续响应头中缓存标记是否变化；若指向目录级规则，应暂停批量改链，先核对边缘配置与源站路径是否一致，否则可能在源站补一堆跳转却绕不开边缘规则。
保留能证明“请求是否到达源站”的日志证据
源站正常这句话，必须由源站访问日志支撑，而不是由“我在源站打开是好的”支撑。要保留异常时间窗口内源站的访问日志片段，包含请求路径、状态码、时间、来源IP或回源标识。然后与边缘异常的时间戳对齐。
如果边缘报404的时间段内，源站日志里没有对应路径的任何请求，说明请求没到源站，问题在边缘到源站之间或边缘自身。如果源站日志里有请求但路径已被改写，说明回源路径配置有问题。如果源站日志里有请求且返回200，而边缘仍返回404，缓存旧响应的解释更强。这三种情况对应三种不同的修复动作，日志是唯一能把它们分开的证据。
假设例子：一次边缘404的证据对照
假设某路径在源站返回200，边缘返回404，且边缘响应头带Age: 7200。同一时刻采集到源站访问日志中该路径最近一次请求是两天前，返回404；对照的同目录页面在边缘返回200。据此可以初步判断：边缘缓存里可能存着两天前那次404的副本，而源站已恢复。此时合理的动作是刷新该路径的边缘缓存，然后重新采集响应头，看Age是否归零、状态是否变为200。若刷新后仍为404，再转向核对边缘规则与回源路径，而不是继续在源站加跳转。这个例子中的数字仅用于说明比较方法，不代表任何真实环境的表现。
哪些现象不能单独证明处理正确
刷新缓存后边缘返回200，不能单独证明问题已解决，因为可能只是缓存恰好过期；需要继续观察一段时间内同一路径的响应是否稳定，以及源站日志中回源请求是否恢复正常。反过来，某个统计里该路径的请求量归零，也不能单独证明配置正确，它可能只是流量转移、抓取周期变化或监控口径调整。把“状态恢复”和“原因消除”分开核对，才能避免把临时现象当成修复完成。
另外，robots.txt限制抓取不等于可靠的索引移除，站点地图存在也不保证收录，这些与边缘异常无关的机制不应混进本次判断。本次要盯住的只有一件事：异常发生在源站、边缘还是两者之间。证据对齐后，修复动作才有明确对象，后续复查也才有可比的基线。
