网站死链查询，源站正常而边缘节点异常时应保留哪些证据

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

网站死链查询，源站正常而边缘节点异常时应保留哪些证据

当源站返回 200 而边缘节点返回 404 或 5xx 时，先不要改源站文件或批量提交死链清理。正确动作是保留能区分“源站问题”“边缘缓存问题”“抓取路径问题”三类解释的证据：同一 URL 的源站响应、边缘响应、请求头、时间戳和节点标识。缺少这些，后续任何处理都只能靠猜。

先固定一个可复查的对比请求

选一个具体 URL，而不是选整个目录。用同一路径分别向源站地址和边缘地址发起请求，记录四组信息：

如果源站返回 200 而边缘返回 404，且响应头里出现“命中缓存”或类似标记，说明边缘可能缓存了一个旧结果。如果边缘响应头里没有缓存标记，反而出现回源失败或连接超时，则更可能是边缘到源站的链路问题，而不是源站内容问题。两种情况下要保留的证据不同：前者需要保留缓存键和缓存时间，后者需要保留回源错误码和边缘节点标识。

用响应头区分缓存命中与回源失败

仅看状态码不够。假设一个 URL 在源站返回 200，在边缘节点返回 404，同时边缘响应头显示 X-Cache: HIT 和一个较早的缓存时间。这个组合指向“边缘缓存了旧状态”，而不是“源站文件被删除”。下一步应检查该缓存键是否包含查询参数、UA 或 Cookie；如果包含，换一个不带这些变量的请求再试，观察结果是否变化。

反过来，如果边缘响应头显示回源失败、连接重置或超时，而源站直接请求正常，则问题更可能在边缘到源站的网络或源站对边缘回源请求的限制上。此时应保留边缘节点标识、回源错误码和源站访问日志中对应时间段的记录。没有节点标识，就无法判断是单个节点异常还是整体回源策略异常。

把抓取日志与人工请求分开保存

搜索引擎抓取到的 404 和人工请求得到的 404 不是同一类证据。抓取日志里应核对：抓取时间、抓取 URL、返回状态码、抓取使用的 UA、以及是否来自站点地图或内链。人工请求则应记录发起时间、请求工具、请求头和响应头。两者时间接近但结果不同，说明边缘节点对不同来源的请求处理不一致，这时要保留两组请求的完整头信息，而不是只保留状态码。

如果抓取日志显示 404，但人工请求显示 200，先不要断定抓取工具出错。合理解释包括：抓取时命中了旧缓存、抓取请求被边缘节点按 UA 或 IP 分流、抓取时间早于源站恢复时间。要区分这些解释，需要把抓取时间与源站变更时间、缓存刷新时间对齐。缺少时间对齐，抓取量归零或 404 数量上升都不能单独证明处理正确。

按证据决定下一步动作

根据保留的证据，可以走三条不同的处理路径：

  1. 边缘缓存旧状态：保留缓存键、缓存时间和命中标记，先刷新该 URL 的缓存，再重新请求边缘地址，确认返回 200 且缓存时间更新。
  2. 边缘回源失败：保留边缘节点标识、回源错误码和源站访问日志，检查源站是否对边缘回源请求做了限制，或边缘到源站的链路是否稳定。
  3. 抓取路径与人工路径不一致：保留两组请求的 UA、IP 和请求头，确认边缘节点是否按来源做了不同处理，再决定是否需要调整抓取策略或边缘规则。

每一步动作的结果都应影响下一步：如果刷新缓存后边缘仍返回 404，说明问题不在缓存层，应转向回源链路；如果换一个不带 Cookie 的请求后边缘返回 200，说明缓存键包含了不该包含的变量，应检查边缘缓存配置而不是源站文件。

不要用单一指标下结论

抓取量下降、404 数量上升或某个统计归零，都不能单独证明源站或边缘节点出了问题。它们还可能是抓取频率调整、站点地图更新延迟、日志采样变化或统计口径变化造成的。要形成可复查的判断，至少需要同一 URL 在源站和边缘的对比响应、时间戳、请求头和节点标识。缺少其中任何一项，后续处理都容易误伤正常页面。

把这些证据按 URL 和时间整理成一份可复查的记录，再决定是刷新缓存、调整回源策略还是修改源站内容。这样即使问题再次出现，也能用同一组证据快速判断是旧问题复发还是新变化。

图1 图2
nginx