📍 WDQWDWQD987AAAAA:216.73.216.60
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /731830a1d902.html
📄

死链扫描工具：源站正常而边缘节点异常时应保留哪些证据

当死链扫描工具报告大量失败，而你在源站直接请求同一批 URL 却全部返回 200，问题通常不在页面本身，而在源站与扫描器之间的边缘节点。此时最该保留的不是“扫描失败了多少条”这个总数，而是能区分“源站正常、边缘异常”与“源站其实也不稳定”的对照证据。核心做法是：对同一 URL 同时保留源站直连结果和边缘路径结果，并记录时间、请求头、响应头和节点标识，让两组数据可以逐条比对。

先区分三类失败，再决定留什么

边缘节点异常不是一个单一原因。扫描器看到的失败至少可能来自三种不同层面，证据需求也不同。

• DNS 或连接层失败：表现为解析到不同 IP、连接超时、TLS 握手失败。需要保留解析结果、目标 IP、失败阶段，而不是只看 HTTP 状态码。
• HTTP 响应层失败：边缘返回 403、404、429、5xx，但源站直连是 200。需要保留完整响应头，尤其是缓存状态、回源标识和节点信息。
• 内容层失败：状态码正常，但边缘返回的是错误页、验证页或旧缓存。需要保留响应体摘要或指纹，而不是只记录状态码。

如果你只保留“失败 URL 列表”，这三类会被混在一起，后续无法判断该找 CDN、改缓存规则，还是回源站排查。先按失败阶段分类，再决定每类保留哪些字段，是让证据可用的前提。

对同一 URL 做双路径对照，是整套证据的骨架

最能说明“源站正常而边缘异常”的证据，是同一时刻、同一 URL 的两组结果。假设你有一个页面 https://example.com/a，可以这样取对照：

1. 用扫描器默认路径请求一次，记录状态码、响应头、解析 IP、耗时。
2. 在能直连源站的环境里，用同样方法请求一次，记录同样的字段。
3. 把两组结果按 URL 对齐，标出差异字段。

如果边缘返回 404 而源站返回 200，差异就落在状态码上；如果两边都是 200 但响应体指纹不同，差异就落在缓存或内容替换上。这个动作的价值在于：它把“扫描器说坏了”变成“哪一层、哪个字段坏了”，下一步的排查对象也随之明确。注意，直连源站时要避免经过同一边缘层，否则对照就失去意义。

必须留下的字段，比截图更有用

截图容易缺字段、难比对。更可靠的是保留原始响应和结构化记录。对每个可疑 URL，至少保留以下内容：

• 请求侧：完整 URL、请求方法、请求头（含 User-Agent、Accept、Cookie 中与缓存或分流相关的部分）、发起时间与时区。
• 响应侧：状态码、完整响应头、响应体长度或哈希、最终重定向链。
• 网络侧：解析到的 IP、TLS 证书主体与有效期、连接耗时与首字节耗时。
• 节点侧：边缘返回的节点标识、缓存命中状态、回源标记（如果响应头中有）。

其中响应头和节点标识最关键，因为它们能区分“边缘自己生成了错误”和“边缘回源拿到了错误”。如果响应头显示缓存命中且状态码异常，问题可能在缓存内容；如果显示回源失败，问题可能在源站连通性或回源配置。保留这些字段后，你才能把问题交给对应的一方，而不是笼统地说“扫描报错”。

用可复核的记录方式固定证据

证据要能被别人复查，否则只是你的单次观察。建议把每个 URL 的记录写成可重放的命令或脚本输出，而不是手工抄写。例如，用 curl -sS -D - -o /dev/null 分别对边缘地址和源站地址各执行一次，把输出保存为带时间戳的文件。这样任何人拿到文件都能看到当时的请求头、响应头和状态码。

同时记录扫描器的配置：并发数、超时阈值、重试次数、User-Agent。因为并发过高或超时过短，本身就会制造“源站正常、扫描失败”的假象。如果降低并发、延长超时后失败消失，那说明原先的失败更可能是扫描器压力或边缘限流导致，而不是页面真的坏了。这一步的结果会直接改变下一步：是调整扫描参数，还是继续追边缘节点。

哪些现象不能单独当作结论

有些观察看起来像证据，实际上有多种解释，不能单独用来下判断。

• 扫描请求量或失败数突然归零，不一定代表问题已修复，也可能是扫描被限流、任务未真正执行或范围被改小。
• 边缘返回 404 不一定是页面被删除，也可能是边缘缓存了旧的错误响应，或回源路径配置错误。
• 源站直连 200 不保证所有边缘节点都正常，单个节点的结果不能代表整个边缘网络。
• 响应时间变慢不一定是死链，可能是节点负载、网络抖动或扫描器自身资源不足。

要区分这些解释，需要多节点、多时点的对照记录。单次、单点的结果只能作为线索，不能作为结论。把线索和结论分开记录，后续复盘时才不会被误导。

从证据到处理：先定责任边界再动手

当你手里有了双路径对照记录，下一步不是立刻改配置，而是先判断问题落在哪一方的责任边界内。

1. 如果只有边缘异常、源站稳定，且响应头显示缓存命中，优先检查缓存规则和刷新策略。
2. 如果边缘回源失败而源站直连正常，检查回源地址、回源协议和源站防火墙是否只放行了部分来源。
3. 如果源站也出现间歇失败，问题不在边缘，应回到源站日志和应用层排查。
4. 如果失败只在高并发扫描时出现，先调整扫描参数并复测，再判断是否真的存在死链。

每完成一步，都用同样的对照方法复测一次，确认差异字段是否消失。只有差异字段消失，才能说这一步处理有效；如果差异仍在，说明判断的责任边界不对，需要回到证据重新分类。这样处理，死链扫描工具的报告才会从“一堆失败链接”变成可定位、可验证、可交接的排查依据。