先给出结论:当源站返回正常、但通过 CDN 或其他边缘节点访问同一死链接却出现 404、410 或 5xx 时,你应优先保留三类证据——同一时刻的完整响应头、可复现的请求上下文、以及源站与边缘节点的对照记录。缺少服务器权限时,浏览器开发者工具、curl 命令和公开的 HTTP 状态检测页面仍能完成最小取证。但要注意:这些证据只能证明“此刻不同节点表现不一致”,不能直接推断缓存配置错误或节点故障,仍需进一步区分。
源站正常而边缘节点异常,常见于内容分发网络缓存了旧的 404 响应、边缘节点回源失败、或不同节点部署了不同版本的跳转规则。此时用户看到的死链接状态并不代表源站的真实状态。你需要先确认差异是否稳定存在,而不是偶发网络抖动。
一个可执行的最小动作是:对同一个 URL,分别向源站地址和边缘节点地址发起请求,记录返回码、响应头中的 Cache-Control、Age、X-Cache 等字段。如果边缘节点返回 404 而源站返回 200,且 Age 值较大,说明该 404 可能来自缓存。这一步的结果会直接影响下一步:若差异稳定,继续留存对照证据;若差异随机出现,则应先排查网络路径而非缓存策略。
仅截图浏览器显示“404”不足以支撑后续处理。应保留以下字段的原始值:
HTTP/1.1 或 HTTP/2 状态码,以及对应的状态短语;Date、Age、Cache-Control、Expires;X-Cache、X-Cache-Hits、Via 等边缘节点标识;Location,用于判断是否发生了跳转链;这些字段能帮助区分“缓存了旧的死链接响应”与“边缘节点回源时源站临时不可达”。如果 Age 为 0 且状态码为 5xx,更可能是回源失败;如果 Age 很大且状态码为 404,则更可能是缓存未刷新。注意,robots.txt 的抓取限制不等于可靠的索引移除,它不能解释边缘节点为何返回不同状态码,因此不应把 robots 规则当作主要证据。
如果你没有源站服务器或 CDN 控制台权限,仍可完成以下动作:
curl -I -H "Host: 你的域名" http://源站IP/路径 和 curl -I https://边缘节点域名/路径,保存输出文本。这些动作的结果会决定下一步:如果多个独立节点均返回异常,而源站直接访问正常,则问题更可能位于边缘节点配置或缓存层;如果仅个别节点异常,则更可能是该节点本地故障。无论哪种情况,都不要仅凭一次请求就下结论。
以下现象常被误读,需要额外解释:
假设一个场景:某页面在源站返回 200,但通过边缘节点访问时返回 404,且 Age 为 86400。你保留了该响应头和请求时间。此时可以合理怀疑缓存了旧响应,但不能直接断定“缓存配置错误”,因为也可能是边缘节点上的跳转规则版本落后。下一步应对比多个边缘节点的响应,并检查是否有规则发布记录。若没有权限查看规则,则只能把对照证据交给有权限的同事,并说明当前能排除和不能排除的项。
最终应形成一份包含以下内容的记录:同一 URL 在源站和至少两个边缘节点的请求时间、返回码、关键响应头、请求方法、发起位置。用文字说明哪些差异是稳定复现的,哪些是偶发的。不要只写“边缘节点异常”,而要写“边缘节点 A 在 10:00 返回 404,Age 为 86400;源站同一时刻返回 200;边缘节点 B 返回 200”。这样接手的人才能判断是缓存刷新、规则同步还是节点故障。缺少完整数据时,这份记录本身就是可执行的最小交付物,它不能直接修复问题,但能避免在错误方向上反复操作。