404页面设置，源站正常而边缘节点异常时应保留哪些证据

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

404页面设置，源站正常而边缘节点异常时应保留哪些证据

先给结论：源站返回 404 只能证明回源那一次请求的结果，不能证明用户拿到的是这个结果。当边缘节点异常时，你至少要保留四类证据——带时间戳的请求与响应头、边缘与源站的响应差异、节点标识与缓存状态、以及可复现的请求参数。缺了任何一类，后续排查都会退回到“我这边是好的”这种无法对质的争论。

先固定一个可对质的请求，而不是反复刷新页面

常规做法是打开浏览器刷新几次，看到源站正常就认为问题不存在。这一步的遗漏条件是：浏览器请求可能命中了不同的边缘节点，也可能命中了缓存，你看到的“正常”和用户看到的“异常”根本不是同一次响应。

可执行的动作是构造一个固定请求，用命令行工具指定解析到某个边缘 IP，并带上一个唯一查询参数避免缓存命中，例如 curl -sI -H "Host: example.com" "http://203.0.113.10/old-path?probe=20240101a"。假设该请求返回 200，而同一路径从另一个边缘 IP 返回 404，这就把问题从“页面是不是存在”转成了“哪些节点给出了不同结果”。下一步该做的是收集这两个 IP 的节点标识，而不是继续改源站配置。

必须留下的四类证据及各自的判断价值

证据不是越多越好，而是每一类都要能回答一个具体问题。

如果只保留状态码截图，你无法判断边缘返回的是自己生成的 404，还是把源站的响应改写了。这两者的处理方向完全不同：前者要查边缘规则，后者要查回源链路。

用一组对照把“源站正常”拆成可判断的分支

把直连源站和经边缘的响应放在一起，通常会落进下面几种情况，每种指向不同的下一步。

  1. 源站 200、边缘 404，且响应头里没有回源标识：异常发生在边缘内部，优先检查该节点上的路径匹配、重写或拦截规则。
  2. 源站 200、边缘 404，但响应头显示已回源：检查回源请求携带的 Host、路径和协议是否被改写，源站可能因为 Host 不匹配而返回 404。
  3. 源站 404、边缘 404：源站本身对该路径就是 404，问题不在边缘，回到源站的路由或文件配置。
  4. 源站 200、边缘 200，但用户仍看到 404：说明你复现的请求和用户的请求不是同一个，需要补充客户端 IP、UA、协议版本等参数再试。

这个分支表的作用是让你在收集证据前就知道哪一类证据会决定判断。比如第 2 种情况，如果没有保留回源请求的 Host 头，你会误以为边缘无差别地返回 404，从而去改一个本来正常的边缘规则。

为什么“请求量归零”不能单独作为处理正确的证据

有人会盯监控曲线，看到某条路径的 404 计数掉到零就认为修好了。这个推断不成立，因为计数归零还有至少三种合理解释：该路径的流量本身下降了；监控埋点改动了统计口径；边缘把响应改写成了别的状态码，不再计入 404 统计。

要排除这些解释，需要把计数变化与前面保留的响应头证据对齐：同一路径在同一时间窗口内，直连源站和经边缘的状态码是否一致。只有计数变化和响应状态一致，才能说这个变化反映了处理结果。否则计数只是另一个需要解释的现象。

把证据整理成一份可交接的记录

排查往往不只一个人参与，所以证据要按“请求—响应—节点—时间”的格式整理，而不是散落在聊天记录里。一份可用的记录至少包含：请求的完整 URL 与方法、解析到的边缘 IP 与节点标识、响应状态码与关键响应头、直连源站的对照结果、以及采集时间。

这份记录的价值在于，当你把问题交给网络或边缘侧时，对方能直接复现，而不是先花一轮沟通确认“你测的是哪个节点”。如果记录里缺少节点标识，对方很可能在自己的节点上测出正常，然后回复“无法复现”，排查就此中断。

最后要明确一点：边缘异常和源站异常的处理责任方通常不同。在证据不足以区分两者之前，任何配置改动都可能把问题从一个节点扩散到更多节点。先固定请求、再对照响应、最后才动配置，这个顺序比急于恢复更省时间。

图1 图2
nginx