死链修复工具：源站正常而边缘节点异常时应保留哪些证据
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /1718a083e431.html
📄
死链修复工具：源站正常而边缘节点异常时应保留哪些证据
先给结论：当源站返回正常而边缘节点仍报错时，最值得保留的不是“修复成功”的截图，而是能同时证明源站响应、边缘响应、请求路径和时间的原始记录。因为“源站正常”只说明回源这一跳没问题，不能推出边缘缓存、节点配置或回源链路已经一致。缺少边缘侧证据时，你无法判断是缓存未刷新、节点回源失败，还是修复根本没覆盖到问题 URL。
先分清两个解释：缓存层没更新，还是回源链路没打通
边缘节点异常通常落在两类原因上，而它们需要的证据不同。
- 解释一：边缘缓存仍是旧的错误响应。源站已修好，但节点上的缓存副本未过期或被单独保留。此时边缘返回的仍是旧状态码或旧跳转，和源站当前行为不一致。
- 解释二：节点回源时没有拿到正确结果。节点向源站发起的请求被拦截、超时或走了不同入口，导致节点自身无法生成正常响应。这种情况下即使源站对浏览器正常，节点仍会失败。
两者的共同点是“源站看起来正常”，区别在于错误发生在哪一跳。只保留浏览器截图或源站 curl 结果，无法区分它们。
能区分两种解释的证据：同一 URL 的分层响应记录
关键动作是：对同一个问题 URL，分别记录源站直连和边缘访问的响应，并保留请求头与时间戳。假设某条旧链接在源站返回 301，而边缘返回 404，这组对照就能把问题锁定在边缘层，而不是源站配置。
需要保留的证据至少包括：
- 源站直连响应。记录状态码、响应头中的缓存相关字段、跳转目标，以及记录时间。这是判断“源站是否真的正常”的基线。
- 边缘访问响应。用同一路径访问边缘，记录状态码、响应头和返回内容摘要。与源站记录放在一起对照。
- 请求路径与入口。注明请求经过的域名、协议和路径，避免把不同入口的结果混为一谈。
- 时间戳与顺序。修复动作、缓存刷新动作和两次观测的时间要能对上，否则无法判断是“没生效”还是“生效后又回退”。
如果边缘响应头里带有缓存命中或回源相关的标记，把它一并留档。它能帮助判断节点是直接返回了缓存，还是尝试回源但失败。若没有这类标记，至少保留边缘与源站的响应差异本身。
为什么“抓取量归零”不能单独证明修好了
有人会拿抓取工具对问题 URL 的请求量下降或归零当作修复成功的证据。这个推断不成立。请求量归零还可能来自：抓取频率本身波动、robots.txt 限制、站点地图未更新、URL 被其他规则排除，或者工具只是暂时降低了该路径的抓取。这些原因与边缘是否修好没有必然关系。
因此，抓取量只能作为辅助信号，不能替代分层响应记录。真正能说明问题的，还是源站与边缘在同一时间点对同一 URL 的响应对照。
一个假设例子：怎样用证据决定下一步
假设某旧商品页在改版后应跳转到新页。源站直连返回 301 到新页，边缘访问返回 404。保留这组对照后，可以这样推进：
- 如果边缘返回的是旧缓存副本，且刷新后变为 301，说明问题在缓存层，下一步是确认刷新覆盖范围，而不是继续改源站规则。
- 如果刷新后边缘仍返回 404，但源站始终正常，说明节点回源这一跳可能有问题，下一步应检查边缘回源配置和请求头，而不是反复刷新缓存。
- 如果边缘和源站都返回 301，但用户仍看到错误页，说明问题可能不在这一层，需要转向页面内跳转或前端路由，而不是继续在边缘侧加证据。
这个例子的数字和状态码只用于说明比较方法，不代表任何真实项目结果。它的价值在于：同一组证据可以排除一种解释，并把下一步动作限定在更小的范围。
留档时容易漏掉的两点
第一，记录要能复查。只写“已修复”没有意义，要保留原始响应片段、时间和对同一 URL 的两次观测。第二，注意 robots.txt 和站点地图的边界：robots.txt 的抓取限制不等于可靠的索引移除，站点地图也不保证收录。它们不能用来证明边缘节点已经恢复正常，只能作为抓取行为的背景信息。
把这些证据按 URL 和时间整理好，再决定是刷新缓存、检查回源，还是把问题交给下一层处理，判断才有依据。
