404错误排查：源站正常而边缘节点异常时应保留哪些证据
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /4a54f68c0b5a.html
📄
404错误排查：源站正常而边缘节点异常时应保留哪些证据
当源站直接访问返回200、边缘节点却返回404时，先不要改源站配置。此时应保留两类证据：一是能证明源站确实正常的原始响应记录，二是能证明边缘节点返回404的请求与响应头。两者缺一，后续判断只能靠猜。是否立即切流量，取决于404是稳定复现还是间歇出现。
先分清两种条件：稳定复现与间歇出现
稳定复现指同一URL、同一节点、同一请求头，连续多次都返回404。这种情况下，证据重点放在节点侧的响应头与缓存状态。间歇出现则同一URL有时200、有时404，重点转为带时间戳的对照记录，因为单次抓取无法说明问题范围。
判断依据可以这样区分：如果换一个边缘节点或换一个出口IP后404消失，说明问题与特定节点或线路有关；如果所有节点都404而源站直连正常，则更可能是边缘回源路径或缓存键配置问题。注意，抓取量归零或某项监控指标掉零并不能单独证明是边缘故障，也可能是监控探针本身走了不同路径、被限流，或统计口径变化。
源站侧要保留的证据
在源站服务器上，用绕过边缘的方式请求同一URL，并记录以下内容：
- 请求的完整URL、方法、Host头、查询串
- 响应状态码、响应时间、响应体长度
- 源站访问日志中对应那条记录，包含客户端IP（应显示为边缘回源IP）和User-Agent
- 若源站有应用层日志，保留路由匹配结果，证明请求命中了正确页面而非兜底404
这些证据的作用是排除源站自身路由、重写规则或后端服务的问题。如果源站日志里根本没有这条回源请求，说明请求在边缘就被拦截或直接判为404，下一步应查边缘的缓存与回源策略，而不是继续查源站。这就是一个实际动作影响下一步的例子：源站日志有无对应记录，直接决定排查方向。
边缘节点侧要保留的证据
边缘侧证据的核心是响应头和节点标识。用命令行工具请求时，保留完整响应头，重点关注能说明404来源的字段，例如表示由边缘直接生成还是回源后转发的标记、缓存命中状态、以及节点或POP标识。不同服务商的头字段命名不同，需要按实际返回逐项核对，不能套用固定字段名。
同时保留：
- 请求发出的时间（精确到秒）与出口IP
- 返回404的节点标识或线路信息
- 同一时刻从另一条线路请求同一URL的结果
- 若经过CDN，保留缓存键相关配置的当前值，例如是否把查询串、Cookie或某个请求头纳入缓存键
假设一个场景：同一URL带查询串?v=2时源站返回200，边缘返回404；去掉查询串后边缘也返回200。这提示边缘的缓存键或回源URL拼接规则可能丢弃了查询串。此时应保留两次请求的完整URL和响应头做对照，再决定是调整缓存键还是调整回源规则。这个例子是假设性的，用于说明比较方法，不代表任何真实平台行为。
什么情况下不该继续保留证据而应先恢复
如果404出现在核心转化路径上，且已确认源站正常、边缘异常稳定复现，继续收集证据的代价可能高于先切回源站直连或回退到上一个已知正常的边缘配置。此时仍应保留切换前的最后一份证据，因为回退后异常可能消失，现场就再也复现不了。
反之，如果404只出现在低频页面或非关键路径，可以按上面的清单完整取证后再处理。例外是：若异常伴随其他症状，例如同一节点上多个不相关域名同时404，优先怀疑节点级故障，取证重点转向节点维度的整体响应，而不是单个URL。
证据整理后的下一步
把源站日志记录、边缘响应头、两条线路的对照结果放在一起，通常能收敛到三个方向之一：边缘缓存键配置、回源URL改写规则、或特定节点/线路的转发异常。每个方向对应的修改动作不同，所以证据里必须能区分它们。若证据只能证明“边缘返回404”，无法说明是缓存命中还是回源失败，就还需要补一次禁用缓存后的请求对照，否则修改可能落在错误的方向上。整理证据时不要只留截图，保留原始响应文本和日志行，才能在后续对比中复用。
