死链检查工具：源站正常而边缘节点异常时应保留哪些证据
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /8350f7038de9.html
📄
死链检查工具：源站正常而边缘节点异常时应保留哪些证据
当死链检查工具在源站直连时返回正常、经边缘节点却返回错误，先不要急着改源站。这个矛盾通常指向两类原因：一类是边缘缓存中仍保存着旧响应或旧重定向，另一类是边缘与源站之间的回源链路、节点配置或证书校验出现偏差。要区分它们，关键是保留能证明“哪个环节返回了什么”的证据，而不是只留一张失败截图。
先固定请求路径，避免证据互相污染
同一个URL在源站和边缘节点得到不同结果时，最容易犯的错误是两边用不同的请求条件去测。应先用同一组条件分别请求，并记录差异。具体动作是：对同一URL分别发起直连源站和经边缘节点的请求，固定Host、路径、查询串、请求方法、协议版本和User-Agent，然后保存完整响应头与响应体片段。
这样做的结果是，你能看到差异究竟出现在状态码、Location、Cache-Control、Age、Via、X-Cache一类字段，还是出现在响应体内容。若源站返回200而边缘返回404或重定向，且边缘响应头里带有缓存命中或回源标识，就说明问题更可能在边缘层，而不是源站文件本身。下一步应转向边缘缓存与回源配置，而不是继续在源站上找文件。
解释一：边缘缓存保留了过期响应
边缘节点为了降低回源压力，会按缓存策略保存响应。如果某个URL曾经返回过301、404或错误页，而缓存时间较长，即使源站后来恢复正常，边缘节点仍可能继续返回旧结果。此时死链检查工具从外部看到的是“坏”的，但源站直连是“好”的。
能支持这一解释的证据包括：边缘响应中出现较高的Age值、明确的缓存命中标识、与源站当前响应不一致的缓存控制字段，以及同一URL在不同边缘节点或不同地区返回不一致。若在刷新缓存后短时间内恢复正常，随后又复现，则要怀疑缓存键设计或回源策略，而不是简单认定“已经修好”。
解释二：回源链路或节点配置异常
另一种情况是边缘节点根本没有拿到源站当前响应。可能原因包括回源DNS解析到旧地址、节点到源站的网络路径异常、源站对边缘回源IP做了限制、协议或端口不匹配、证书校验失败，以及边缘侧的重写规则把请求改到了错误路径。
支持这一解释的证据与缓存问题不同：边缘响应中看不到正常的缓存命中标识，Age值很低或不存在，错误可能表现为502、503、504或连接超时；同一URL从多个边缘位置请求结果不稳定；源站访问日志中看不到来自边缘节点的回源记录，或看到的回源路径与预期不符。若源站日志显示边缘回源请求被拒绝、被重定向到登录页，或请求路径被改写，就应优先检查边缘回源配置和访问控制，而不是继续刷新缓存。
用一组对照请求把两种解释分开
假设有一个页面，源站直连返回200，经边缘节点返回404。可以按下面顺序做对照，并把每步结果存档：
- 记录边缘响应的完整状态行、响应头和响应体前若干字节，重点看Age、缓存命中标识、Location和错误页特征。
- 用同一路径和查询串直连源站，保存响应头和响应体，确认源站当前确实返回200。
- 在边缘侧发起一次强制回源或缓存刷新后立即重测，记录是否短时恢复。
- 若短时恢复后又失败，检查源站访问日志中是否有对应的边缘回源记录，以及回源请求的路径、方法和来源标识。
- 若日志中没有回源记录，转向检查边缘到源站的DNS、网络、证书和访问控制；若日志中有回源记录但路径不对，转向检查边缘重写规则。
这组动作的价值在于：刷新缓存只能证明“缓存可能是变量”，不能证明“缓存就是原因”。只有把刷新前后的响应、源站日志和回源路径放在一起，才能判断下一步该动缓存策略还是动回源配置。
证据清单要包含时间、位置和原始响应
为了让后续处理可复查，至少保留以下内容：
- 请求时间，精确到分钟，并注明时区。
- 请求的完整URL、Host、路径、查询串、请求方法和协议。
- 边缘节点返回的状态码、响应头和响应体片段。
- 源站直连返回的状态码、响应头和响应体片段。
- 边缘响应中与缓存、回源、节点位置相关的字段。
- 源站访问日志中对应时间窗口的回源记录，若没有则明确记录“未观察到”。
- 执行过的刷新、回源或配置变更动作，以及动作后的复测结果。
不要只保留“死链检查工具报告404”这一条结论。工具报告是线索，不是证据链。原始响应和日志才能说明是谁返回了404、在什么条件下返回、是否与缓存或回源有关。
哪些现象不能单独证明原因
请求量下降、抓取量归零或某个工具报告消失，都不能单独证明边缘异常已经处理正确。它们还可能有其他解释：检查任务未运行、抽样范围变化、访问控制拦截了检查请求、DNS解析变化、源站本身短暂不可用，或者工具只检查了部分节点。因此，判断修复是否成立，应回到同一组对照请求：源站和边缘是否返回一致、源站日志是否出现预期回源、缓存刷新后是否稳定，而不是只看某一个统计数字。
另外，robots.txt中的抓取限制不等于可靠的索引移除，站点地图也不保证收录；这些与边缘节点异常不是同一层问题，不应混在同一份证据里。若问题同时涉及搜索引擎、平台推荐或广告渠道，应分别核对各自的抓取与展示条件，不要用一套证据解释所有渠道。
把源站响应、边缘响应、回源日志和变更动作按时间顺序放在一起，才能让下一次复测有明确对照；如果边缘响应中的缓存标识与源站日志中的回源记录同时存在且互相矛盾，优先核查边缘缓存键和回源重写规则，而不是继续修改源站内容。
