死链检查方法：源站正常而边缘节点异常时应保留哪些证据
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /4c02837e875a.html
📄
死链检查方法：源站正常而边缘节点异常时应保留哪些证据
先给有条件的结论：如果源站对同一 URL 返回 200，而边缘节点返回 404 或 5xx，应优先保留“同一时刻、同一路径、同一请求头”下的边缘响应证据，而不是只保留源站截图。因为死链判断最终取决于抓取方看到的那一跳，边缘节点才是抓取方实际到达的位置。但这条结论有一个反例：如果边缘异常只出现在带特定 Cookie、特定 UA 或特定地区出口的请求上，那么只保留一次默认请求的边缘响应，反而会把问题误判为全局死链。
先分清两种取舍：保留边缘证据还是保留源站证据
两种做法都成立，但条件不同。选择保留边缘证据，适用于抓取工具、用户或监控节点已经报告 404，而源站自测正常的情况；代价是边缘日志通常保留时间短、字段少，事后补证困难。选择保留源站证据，适用于怀疑是回源配置、缓存键或负载均衡把请求送错后端的情况；代价是源站正常不能证明抓取方看到的就是正常。
实际动作：在发现异常的那一刻，先对同一 URL 分别向源站地址和边缘地址发起请求，记录两者的状态码、响应头中的 Cache-Control、Age、X-Cache 类字段以及响应体前若干字节。这个动作的结果决定下一步：如果边缘与源站状态码不同，继续查缓存键和回源规则；如果两者相同，问题可能不在边缘，应转向源站路由或应用层。
必须保留的证据类型与最小集合
证据要能回答三个问题：谁发的请求、请求到了哪里、返回了什么。建议至少保留以下内容，且尽量带时间戳：
- 请求侧：完整 URL、请求方法、请求头中的 Host、User-Agent、Accept-Encoding、Cookie 是否存在，以及发起请求的出口 IP 或节点标识。
- 响应侧：边缘返回的状态码、响应头全文、重定向链的每一跳地址与状态码。
- 对照侧：同一时刻源站直连的响应状态码与响应头，用于证明源站是否正常。
- 时间侧：异常首次出现时间、持续时长、是否可重复复现，以及复现时使用的相同请求条件。
不要只保留一张状态码截图。状态码相同但响应头不同，可能指向不同的缓存对象；响应头相同但请求头不同，可能指向不同规则。缺少请求条件的证据，无法判断异常是全局还是条件触发。
一个会推翻结论的反例
假设边缘节点对默认请求返回 200，但对携带某类 Cookie 的请求返回 404。此时若只保留默认请求的证据，会得出“边缘正常”的结论，而真实死链只对特定访问者出现。反过来的反例同样成立：边缘对默认请求返回 404，但对源站直连返回 200，若据此认定边缘全局故障，也可能忽略源站只对边缘回源 IP 返回 200、对普通用户返回 404 的情况。
因此，证据是否充分，取决于是否覆盖了异常触发的条件组合。至少应对比两组请求：一组是报告异常的原始条件，一组是去掉可疑条件后的对照条件。两组结果不同，说明异常是条件性的；两组结果相同，才更接近全局性问题。
证据保留后，下一步怎么走
拿到上述证据后，按以下顺序推进，每一步都以上一步的结果为条件：
- 若边缘与源站状态码不一致，先核查缓存键是否包含 Host、路径、查询参数或 Cookie。缓存键遗漏会导致不同请求命中同一份错误缓存。
- 若状态码一致但响应头中的缓存状态不同，核查边缘是否缓存了源站某次错误响应，以及该响应的缓存时长设置。
- 若异常只在特定节点或地区出现，保留该节点标识与出口信息，用于判断是节点配置差异还是回源链路问题。
- 若以上都无法复现，保留原始报告的时间、URL 与请求条件，作为后续监控比对的基线，而不是直接判定为误报。
需要说明的是，边缘返回 404 不等于该 URL 一定应从索引中移除；robots.txt 的抓取限制也不等于可靠的索引移除手段。站点地图不保证收录，HTTPS 也不保证安全无漏洞或排名。证据保留的目的是让判断可复查，而不是替代对具体搜索引擎支持情况的分别核查。完成证据固定后，下一步应带着完整的请求与响应对照记录去核查边缘配置，而不是仅凭单一状态码下结论。
