死链接检测工具：源站正常而边缘节点异常时应保留哪些证据
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /9040193458dc.html
📄
死链接检测工具：源站正常而边缘节点异常时应保留哪些证据
先给结论：当源站返回正常、边缘节点却报错时，不要急着改源站配置。你手上这份“疑似死链清单”只是线索，真正要保留的是能证明“同一URL在不同节点返回不同状态”的对照证据。先把证据固定下来，再决定是清理缓存、调整回源规则，还是回退节点变更。
先确认你面对的是边缘异常，而不是源站真的坏了
死链接检测工具通常从一个出口发起请求，它给出的404、410或超时，只代表“从那个位置看，这个URL不可达”。如果源站直连返回200，而边缘节点返回404，这两条记录必须并存，不能只留下工具报错的那一条。
判断依据可以分三层：源站直连响应、边缘节点响应、工具自身请求路径。三者不一致时，优先怀疑边缘缓存、回源规则或节点配置，而不是内容本身被删除。若源站直连也异常，问题才回到内容与源站配置层面，处理顺序完全不同。
必须固定下来的原始证据清单
证据的价值在于可复现、可对照、可追溯时间。以下项目建议在动手修复前逐条留存：
- 同一URL在源站直连与边缘节点上的完整响应头，重点保留状态码、
Cache-Control、Age、Via、X-Cache一类缓存标识字段。 - 请求发生的时间戳与时区，精确到分钟，便于和节点变更、缓存刷新记录对齐。
- 发起请求的出口位置或节点标识，说明这条记录来自哪里，避免把单节点结果当成全局结论。
- 死链接检测工具输出的原始结果文件，不要只截图汇总页，保留逐条URL与状态码。
- 同批URL中正常返回的对照样本，用来证明异常是局部现象还是整站现象。
这些字段里，响应头比状态码更能说明问题来源。状态码只告诉你结果，缓存标识字段才可能解释为什么同一URL在不同节点表现不同。
一个假设例子：怎样用对照证据缩小范围
假设某页面在源站直连时返回200，响应头无缓存标记；从边缘节点请求时返回404，且带较长的Age值。此时一个合理解释是边缘缓存了一份旧的错误响应，而不是源站内容消失。
下一步动作：先保留这份对照记录，再对该URL做一次定向缓存刷新，然后从同一节点重新请求并记录新响应。如果刷新后恢复200，说明问题集中在缓存层，后续要检查的是缓存策略与回源触发条件；如果刷新后仍为404，才需要转向回源规则或节点配置排查。这个动作的意义在于用一次受控变更区分两种原因，而不是同时改动多处配置，导致无法判断是哪一步起了作用。
哪些现象不能单独作为结论
请求量下降、工具报错数上升，都可能有多种解释：出口网络抖动、节点临时故障、限流、缓存过期策略变化，都可能造成类似结果。单一指标变化不能证明“边缘节点一定有问题”，也不能证明“源站一定正常”。
因此证据要交叉：源站直连、边缘节点、工具出口三条路径至少各留一份记录，再结合变更时间线判断。缺少对照时，任何结论都只是猜测。
证据齐了之后，按什么顺序决策
先看异常是否只出现在特定节点：是，则优先处理该节点缓存与配置；否，则检查回源链路。再看响应头是否显示缓存命中：是，先做定向刷新并复测；否，转向源站与边缘之间的转发规则。
需要提醒的是，如果后续涉及用robots.txt限制抓取或提交站点地图来“处理”这些URL，要清楚前者不等于可靠的索引移除，后者也不保证收录，它们解决的是抓取与发现层面的问题，和边缘节点返回错误是两件事，不要混在同一轮变更里。
把每一步动作和复测结果按时间顺序记下来，这份记录本身就是下一次判断的基线。源站正常而边缘异常的场景，最终靠的不是某个工具的单次输出，而是你能拿出的那组可对照、可复现的原始证据。
