测试死链接：源站正常而边缘节点异常时应保留哪些证据
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /33fa103d931d.html
📄
测试死链接：源站正常而边缘节点异常时应保留哪些证据
当源站返回正常、边缘节点却返回 404 或 5xx 时，最该保留的不是“死链接数量”，而是能复现差异的请求与响应证据。具体说，至少留住同一 URL 在源站直连和边缘节点两条路径上的完整响应头、请求时间、节点标识和响应体片段。只有这些证据能让你判断该改链接、改缓存规则，还是先退出修复动作。
先分清两种取舍：改链接还是改边缘配置
出现源站正常、边缘异常时，常见做法有两种：一是把该 URL 当作死链接直接替换或删除；二是保留原 URL，转而排查边缘缓存与回源配置。选择条件取决于证据指向哪一层。
- 如果边缘响应头里带有缓存命中标记，且响应体是旧版本或错误页，通常指向缓存层，此时改链接会掩盖问题，代价是下次同规则的其他 URL 仍会异常。
- 如果边缘回源请求本身就失败，而源站直连正常，问题更可能在回源链路或节点侧，保留原 URL 并记录回源日志更有价值。
- 如果只有个别节点异常、其他节点正常，直接改链接的代价最大，因为它会把一个节点级问题误判为内容级问题。
这里的关键动作是：先对同一 URL 分别发起源站直连请求和边缘请求，把两次响应并排保存。这个动作的结果会直接决定下一步——若差异只出现在边缘，就不要进入批量替换链接的流程。
必须保留的四类证据
证据要能支撑复查，而不只是当下判断。建议按下面四类留存：
- 请求侧信息：完整 URL、请求方法、请求头中的 Host、User-Agent、Accept-Encoding，以及发起请求的时间戳和时区。
- 响应侧信息：状态码、响应头全文，尤其是缓存相关头、回源相关头和节点标识头；响应体的前若干字节或错误页原文。
- 路径对比：同一 URL 在源站直连与边缘节点的两组响应，标注各自使用的解析地址或节点。
- 环境说明：请求从哪个网络位置发出、是否经过代理、是否携带登录态。缺少这一项，复查时很难排除本地网络因素。
其中响应头全文最容易被忽略。只截一个状态码，无法区分是缓存返回的旧 404，还是回源失败产生的 5xx。保存完整响应头，才能让后续判断有依据。
用一组假设对比判断该不该退出修复
假设某 URL 在源站直连返回 200 且内容正确，在边缘节点返回 404，响应头显示缓存命中且缓存时间早于最近一次内容更新。此时可以推断：边缘缓存里存的是更新前的旧状态。这个推断只是假设，需要再用一次强制回源或缓存刷新后的请求来验证。
验证动作是：对同一 URL 发起一次绕过缓存的请求，再对比响应。如果绕过缓存后恢复正常，说明问题在缓存层，应保留原 URL，转而处理缓存规则；如果绕过缓存后仍然异常，说明问题不在缓存，继续改链接没有意义，应保留证据并转向回源链路排查。这个动作的结果直接决定下一步走向，而不是凭状态码单独下结论。
哪些现象不能单独证明处理正确
边缘节点异常消失、抓取量归零或某次测试不再报错，都不能单独证明修复正确。它们还有其他合理解释：节点可能被临时摘除、缓存可能自然过期、测试请求可能命中了另一条路径。要排除这些解释，需要同一 URL 在多个节点、多个时间点的对比记录。
另外，用 robots.txt 限制抓取并不等于可靠的索引移除，站点地图也不保证收录。这些手段与边缘节点异常是不同层面的问题，不能互相替代。若确实需要处理索引状态，应分别核查不同搜索引擎的支持情况，而不是把边缘修复当作索引修复。
保留证据后的实际动作顺序
拿到上述证据后，建议按这个顺序推进：先确认异常是否只在边缘出现，再确认是否与缓存相关，最后才决定是否改动链接或内容。每一步都以前一步的证据为前提，避免在原因未明时批量替换 URL。批量替换的代价是丢失原始对照，之后再想复查源站与边缘的差异，就缺少可比的基线。
如果证据显示问题只在个别节点且与缓存无关，保留原 URL 并继续观察通常比立即改链接更稳妥；如果证据显示边缘持续返回错误且回源也失败，才需要考虑临时下线或替换该 URL，同时保留完整记录以便回溯。
