404状态码：源站正常而边缘节点异常时应保留哪些证据
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /8071d976ea88.html
📄
404状态码：源站正常而边缘节点异常时应保留哪些证据
先给结论：源站返回正常的404，而边缘节点返回异常时，需要保留的证据不是“一个截图”，而是能同时证明源站响应、边缘响应、请求路径与时间对应关系的四类材料。只有把源站日志、边缘日志、带时间戳的响应头和请求URL放在同一时间轴上，才能判断问题出在缓存、回源、规则改写还是节点本身。缺少任何一类，后续处理都会变成猜测。
第一步：把源站响应固定下来，证明“源站正常”
“源站正常”不能只凭浏览器打开首页正常来判断。你需要针对出问题的那个具体URL，在源站侧留下可复查的记录。具体动作是：在源站服务器或应用日志中，按时间窗口筛选该URL的请求，记录状态码、响应时间、回源IP和User-Agent。如果源站对同一URL稳定返回404，说明源站认为该资源不存在；如果源站返回200而边缘返回404，问题方向完全不同。
这里要区分两种“正常”：一种是源站确实返回404，这是内容层面的正常；另一种是源站返回200，但边缘把它改写成了404，这是链路层面的异常。假设某页面源站日志显示200、响应体长度约12KB，而边缘日志显示404、响应体为空，那么证据链就指向边缘处理环节，而不是源站内容缺失。这个判断会直接决定下一步是去查内容，还是去查边缘规则。
第二步：保留边缘节点的原始响应，而不是只看状态码
边缘节点异常最常见的情况是：状态码是404，但响应头里带着缓存命中、回源失败或规则匹配的痕迹。你需要保存完整响应头，重点看这几项：
cache-control与age：判断该404是否来自缓存，而不是实时回源。x-cache、cf-cache-status或同类边缘标识：判断请求是否命中缓存层。server、via：判断响应由哪一层生成。- 响应体内容：空响应体与自定义404页面，指向不同的处理逻辑。
如果边缘返回的404带有较长的 age，说明这个404可能已经被缓存。此时清除缓存后重新请求，若源站返回200而边缘恢复200，就能证明是缓存了错误状态。若清除缓存后边缘仍返回404，则要转向查回源配置和边缘规则，而不是继续在缓存上打转。
第三步：用同一时间戳对齐请求，避免证据互相矛盾
源站日志和边缘日志的时间戳经常不在同一时区，直接对比会得出错误结论。你需要把两边日志统一到UTC，或者至少记录下各自的时区偏移。然后按请求URL和请求时间，找到同一次请求在两侧的记录。可用的对齐字段包括：请求时间、URL路径、查询字符串、客户端IP、请求ID（如果边缘会透传）。
如果边缘日志里能看到一个请求ID，而源站日志里没有对应记录，说明请求可能根本没有回源，问题在边缘层；如果源站有记录但边缘没有，说明边缘可能提前拦截或返回了缓存。这个区分是后续动作的分水岭：前者查边缘规则和节点状态，后者查日志采集和缓存策略。
第四步：保存请求路径与规则配置的快照
仅凭日志还不够，因为边缘节点的行为受规则配置影响。你需要保存出问题时间段内的边缘规则快照，包括重写规则、回源规则、缓存规则和状态码处理规则。重点检查是否存在把源站404改写为其他状态、或把其他状态改写为404的规则。
一个常见的遗漏条件是：规则里配置了“源站返回404时返回自定义页面”，但自定义页面本身又触发了另一条规则，最终对外表现为404。这种情况下，源站日志正常，边缘日志也显示404，但根因是规则叠加。保留规则快照，才能复现和验证这个判断。
第五步：把证据整理成可复现的最小集合
处理这类问题时，不需要把所有日志都导出。你只需要保留一个最小集合，足以让他人复现判断：
- 出问题URL的完整请求，包括协议、主机、路径和查询参数。
- 源站对该请求的响应状态码、响应时间和响应体长度。
- 边缘节点对该请求的响应状态码、完整响应头和缓存标识。
- 同一时间窗口内，两侧日志中该请求的记录。
- 该时间段内生效的边缘规则快照。
这个集合的作用是：当问题再次出现时，你可以用同样的请求去验证规则是否被修改、缓存是否被清除、节点是否被切换。如果验证结果与之前一致，说明问题稳定存在；如果结果不同，说明存在时间或节点相关的变量，需要进一步缩小范围。
最后要提醒一点：边缘节点返回404并不等于搜索引擎会立即移除该URL。robots.txt的抓取限制不等于可靠的索引移除，站点地图也不保证收录。处理这类问题的目标是让源站与边缘的响应保持一致，而不是用状态码去控制索引结果。只有把证据链固定下来，后续的修复动作才有可验证的基准。
