死链处理，源站正常而边缘节点异常时应保留哪些证据
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /a46d248cf34e.html
📄
死链处理，源站正常而边缘节点异常时应保留哪些证据
结论先说：如果源站返回正常、边缘节点却返回 404 或 5xx，需要保留的不是“死链清单”，而是一组能证明两条链路结果不一致的证据——同一 URL 在源站与边缘节点各自的请求时间、响应状态、响应头和响应体指纹。只有这组证据成立，才能判断该 URL 是真死链还是边缘缓存或回源异常。反例是：如果源站本身也间歇性 404，或者边缘节点返回的是带缓存的旧 200 而源站已改，那么“源站正常”这个前提不成立，下面的证据清单就要换成源站稳定性排查。
先固定同一时刻的两端响应快照
边缘节点异常最容易出现在缓存层，而不是内容层。处理旧内容退出时，常见动作是删除源站文件或改配置，此时边缘节点可能仍持有旧缓存，也可能因为回源失败而返回 404。要区分这两种情况，需要在尽量接近的时间点分别请求源站和边缘节点。
- 记录请求的完整 URL、请求方法、请求时间（精确到秒）、请求来源 IP 或节点标识。
- 记录两端各自的响应状态码、响应头中的
Cache-Control、Age、X-Cache、Via等字段。 - 记录响应体的长度或哈希值，用来判断返回的是同一份内容、旧缓存还是错误页。
实际操作上，可以在同一分钟内用 curl -I 分别请求源站地址和边缘节点地址，把两次输出保存为文本文件。这个动作的结果决定下一步：如果两端状态码不同但响应体哈希相同，说明是状态码层面的差异；如果哈希也不同，则更可能是缓存内容或回源路径问题。
保留回源请求的日志证据，而不只是客户端看到的响应
客户端看到边缘节点 404，不等于边缘节点没有向源站发起请求。需要从边缘节点的访问日志或回源日志中，提取该 URL 对应的回源请求记录。关键字段包括：回源时间、回源目标地址、回源响应状态、回源耗时、是否命中缓存。
假设一个场景：某旧页面在源站被删除，边缘节点仍返回 200 旧内容；另一旧页面在源站保留但边缘节点返回 404。两者的日志会呈现不同模式——前者回源可能没有发生或返回 304，后者回源可能返回 200 但边缘节点仍输出 404。这个差异决定了应该清理缓存还是检查边缘规则，而不是直接删除链接。
需要说明的是，抓取量或请求量归零不能单独证明处理正确。它也可能是采集工具未运行、日志采样丢失或访问路径改变造成的。因此日志证据要与其他证据交叉验证。
保存边缘节点配置与变更记录的快照
边缘节点的缓存规则、回源规则、重定向规则、URL 重写规则，任何一项变更都可能导致源站正常而边缘异常。保留证据时，应同时保存变更前后的配置快照，以及变更时间点。
- 缓存键规则：是否包含查询参数、是否按 Cookie 或设备类型区分。
- 回源规则：回源 Host、回源协议、回源超时设置。
- 重定向与重写规则：是否把旧路径映射到了已删除的目标。
如果配置快照缺失，至少保存变更工单或操作记录的时间戳，并与异常出现时间对齐。这一步的结果会影响下一步：若异常时间与某次配置变更吻合，应优先回滚或复核该变更；若时间不吻合，则应继续排查缓存过期和回源链路。
用对照请求排除误判，再决定保留还是移除
单个 URL 的异常不足以定性。应选取同一目录下仍正常访问的 URL、同一规则命中的其他 URL、以及一个明确已删除的 URL，做三组对照请求。对照结果能帮助区分是单点问题还是规则问题。
假设三组对照中，只有已删除 URL 在边缘节点返回 404，其余正常，那么该 404 可能是预期结果，不需要额外处理。反之，如果仍正常访问的 URL 也在边缘节点返回 404，则说明边缘规则或缓存层存在更广泛的问题，此时不应继续删除更多旧内容，而应先修复边缘节点。
需要提醒的是，robots.txt 的抓取限制不等于可靠的索引移除，站点地图也不保证收录。这些手段与边缘节点异常不是同一层面的证据，不能用来替代两端响应快照。
下一步动作：先复现，再决定是否改源站
在证据齐备之前，不要急于修改源站文件或删除旧内容。正确的下一步是：用保存下来的请求参数，在另一台客户端或另一个边缘节点上复现同一请求。如果复现结果与之前一致，说明异常可重复，可以进入修复流程；如果无法复现，说明可能是瞬时故障或节点差异，应继续收集更多节点样本。
只有确认边缘节点异常可重复、且源站响应稳定正常时，才考虑清理边缘缓存、修正回源规则或调整重定向。每一步操作后，重新保存一份两端响应快照，与操作前的快照对比，确认状态码和响应体指纹的变化符合预期。这样处理死链时，证据链才是完整可复查的。
