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

404 not found，源站正常而边缘节点异常时应保留哪些证据

结论先给：如果源站对同一路径返回正常内容，而用户或抓取工具在边缘节点拿到 404 not found，你要保留的不是“一个截图”，而是一组能同时证明请求路径、节点差异和时间点的证据。核心是让下一次排查能回答三个问题：请求有没有到达源站、边缘节点改写了什么、异常是持续还是偶发。缺少其中任何一类，结论都可能站不住。

先固定请求链路，再谈节点是否异常

边缘节点异常最常见的误判，是把本地网络问题、DNS 解析差异或客户端缓存当成节点故障。要排除这些，先保留能还原请求链路的材料。

• 完整请求与响应头：包括请求的 Host、路径、方法，以及响应状态码、Age、Cache-Control、X-Cache 一类能说明命中的字段。不同厂商字段名不同，以实际返回为准，不要预设字段一定存在。
• 解析结果：同一时刻从不同网络解析到的 IP 或 CNAME，用来判断请求是否真的落在你怀疑的那个节点。
• 时间戳与时区：边缘异常常与发布、回源切换、缓存刷新时间相关，时间不统一会让比对失效。

实际动作：用同一路径分别向源站直连地址和边缘入口发起请求，把两次响应头完整保存。结果如何影响下一步——如果源站直连也返回 404，问题就不在边缘，应转向源站路由或应用层；只有边缘返回 404 时，才继续查节点缓存与回源配置。

区分“边缘缓存了旧 404”与“回源被改写”

这两种原因的处置方式完全不同，但表面现象都是边缘 404。可区分的证据是：

• 带唯一查询串请求同一路径，观察状态码是否变化。若变化，偏向缓存了旧的 404 响应；若不变，更可能是回源链路或节点规则在改写。
• 查看响应头中的缓存命中标记与 Age。命中且 Age 较大，说明这是一份被存下来的旧响应，而不是实时回源结果。
• 对比源站访问日志中是否出现该请求。源站日志没有记录，说明请求可能根本没回源，异常发生在节点内部。

这里必须提醒一个反例：源站日志没有该请求，并不能单独证明节点有问题。日志采样、日志延迟、日志只记录部分状态码，都会造成“看不到”。所以日志缺失只能作为线索，要和响应头、解析结果一起看。

保留内容层面的证据，避免只盯状态码

旧内容或旧系统退出时，常出现“页面其实还有价值，但边缘返回 404”的情况。此时只记录状态码不够，还要保留内容证据，才能判断该路径应该恢复、重定向还是确实下线。

• 源站返回的正文摘要或关键字段，证明内容仍然存在且可用。
• 边缘返回的正文或错误页标识，确认它不是源站内容，而是节点生成的错误响应。
• 该路径此前的正常响应样本（若有留存），用于比对是否发生过内容变化。

假设的例子：某旧系统的一个说明页在源站仍可访问，但边缘对部分区域返回 404。保留上述三类证据后，可以判断这是节点侧问题而非内容已删除，从而决定先修节点而不是直接做重定向。这里数字仅用于说明比较方法，不代表任何真实环境的表现。

证据要能支撑一个明确决定

收集证据的目的不是留档，而是决定下一步。可按下面的顺序推进：

1. 若源站直连正常、边缘稳定返回 404，且响应头显示缓存命中，先按缓存问题处理，刷新后复测同一路径。
2. 若刷新后仍异常，且源站日志持续没有对应请求，再排查节点回源规则与路由配置。
3. 若源站直连也异常，停止在边缘侧投入，转回源站应用与路由层。

每一步都要用同一路径、同一时间基准复测，并把新旧响应头放在一起比对。这样即使问题偶发，也能看出异常是收敛还是扩散，而不是凭单次结果下结论。

哪些情况会让这套判断失效

需要说明适用条件：当边缘节点本身不可观测，或你无法获取源站日志与响应头时，上面的比对方法会失去一半依据，此时只能依靠外部多地点探测，结论强度明显下降。另外，若异常路径涉及动态接口而非静态内容，缓存与回源的表现规律不同，不能直接套用。

下一步动作很具体：把源站直连响应、边缘响应、解析结果、时间戳整理成一份可复查的记录，标注每份证据的获取方式与时间。这份记录会直接决定你是去修缓存、修回源规则，还是回到源站排查，而不是在“到底是哪一层坏了”上反复猜测。