死链测试工具，源站正常而边缘节点异常时应保留哪些证据
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /63a0848491c5.html
📄
死链测试工具，源站正常而边缘节点异常时应保留哪些证据
当死链测试工具在源站直连时返回正常、经边缘节点访问却出现404或5xx，第一件该做的事是保留“同一时间、同一URL、不同路径”的对照证据。核心不是马上让开发改配置，而是先证明异常发生在边缘层而非源站层。若证据只包含边缘节点的失败截图，后续很可能被源站“我这里正常”驳回。
保留三类最小证据：请求、响应、时间戳
证据要能回答两个问题：边缘节点到底收到了什么，源站又返回了什么。建议至少保留以下内容，并确保它们来自同一轮测试。
- 请求侧证据：完整URL、请求方法、请求头中的Host、User-Agent、Accept-Encoding，以及是否经过重定向。这些决定边缘节点把请求转发给哪个源站、走的是HTTP还是HTTPS。
- 响应侧证据：状态码、响应头中的Cache-Control、Age、Via、X-Cache一类回源标记，以及响应体前若干字节。状态码相同但响应头不同，往往指向缓存或回源策略差异。
- 时间戳与路径：记录测试发生的具体时间，并注明请求是直连源站IP、经边缘域名，还是经本地hosts绑定。路径不同，结论的适用范围就不同。
一个实际动作是：用同一台机器、同一时刻分别请求源站地址和边缘地址，把两次原始响应保存为文件。这样做的结果会直接影响下一步——如果两边状态码和响应头一致，问题可能出在本地DNS或测试工具本身；如果状态码不同，才值得进入回源与缓存排查。
区分“边缘异常”的几种可验证原因
边缘节点返回异常，不一定等于边缘节点坏了。以下原因各自需要不同的证据，不能互相替代。
缓存了旧的失败结果
如果响应头里Age较大，或Cache-Control允许较长缓存，边缘可能保留了一次历史失败响应。此时直连源站正常、边缘异常是合理的。可验证动作是带一个随机查询参数再请求一次，绕过缓存键。若带参数后正常，说明问题在缓存层而非源站。
回源路径或协议不一致
边缘节点可能用HTTP回源，而源站只对HTTPS提供正确内容；也可能回源到错误的端口或后端。证据应包含Via、X-Cache等回源标识，以及边缘配置中声明的源站地址。没有这些，无法判断是节点故障还是配置差异。
节点局部故障或灰度差异
边缘通常有多个节点，个别样本成立不代表全部异常。需要记录测试时命中的节点标识（若响应头提供），并在多个地理或网络位置重复。若只有部分节点失败，应保留每个节点的独立响应，而不是合并成一条“边缘异常”结论。
保留、改写还是退出：三种取舍的前提
证据收集完，下一步是决定是否保留原URL、改写跳转，还是暂时退出索引处理。三种选择都有明确前提。
- 保留：适用于源站正常、边缘异常可快速修复，且该URL仍有流量价值。前提是你能确认异常是暂时的，并且修复不需要改变URL结构。保留期间应继续监控，而不是放任。
- 改写：适用于URL本身需要调整，例如源站已迁移而边缘仍指向旧路径。前提是你能控制跳转目标，且跳转不会造成循环。改写前应确认新目标在源站和边缘都返回正常。
- 退出：适用于页面已无对应内容、且确认不应再被访问。注意，用robots.txt限制抓取不等于可靠的索引移除；它只阻止抓取，不保证已收录结果消失。退出决策应基于内容状态，而不是单次边缘异常。
这里有一个假设例子：某页面在源站返回200，边缘返回404，且带随机参数后边缘也返回200。按上述条件，更合理的动作是保留URL并排查缓存键，而不是改写或退出。因为证据指向缓存层，改写会掩盖真正原因。
规模化后例外出现的边界
个别样本成立，不代表可以照搬到全站。当死链测试工具对大量URL批量检测时，边缘异常可能表现为零星的、不可复现的失败。此时要小心两类误判。
第一，把抓取量或失败数归零当作问题已解决。失败数下降还可能是因为测试频率改变、缓存过期、或部分节点被临时摘除。需要结合时间窗口和节点分布判断，而不是只看一个总数。
第二，把一次边缘异常当作源站故障。源站正常而边缘异常的证据链，必须包含直连对照；没有对照，就不能排除测试工具、DNS解析或本地网络的影响。
可操作的下一步是：把证据按“URL—路径—节点—时间—状态码—响应头”整理成可复现的最小记录，交给负责边缘配置的人。若对方能据此复现，才进入修复；若不能复现，应补充节点和网络位置信息，而不是直接扩大改写范围。这样做的结果，是把一次异常从“猜测”收敛为可验证的配置或缓存问题。
