404页面设计：源站正常而边缘节点异常时应保留哪些证据
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /75ff47fd58ae.html
📄
404页面设计：源站正常而边缘节点异常时应保留哪些证据
先给结论：当源站返回正常的404状态，而用户或抓取端在边缘节点看到的是超时、502、200软404或旧页面时，需要保留的证据不是一张截图，而是能同时证明“源站正确”和“边缘偏离”的两组材料。只留其中一组，后续排查会失去比较基准。
两种条件决定证据取舍：可复现与不可复现
边缘异常能否稳定复现，直接决定你要保留什么。稳定复现时，证据重点放在请求链路和响应差异；不可复现时，证据重点放在时间戳、节点标识和原始日志留存，而不是反复截图。
条件一：异常可稳定复现
此时应保留同一URL在源站与边缘节点的完整响应头对照，包括状态码、cache-control、age、via、x-cache一类缓存标识，以及响应体开头若干字节。关键动作是固定请求参数，只改变解析目标或回源路径，让两次请求的差异只剩节点这一项。结果如何影响下一步：如果边缘响应头里出现源站没有的缓存命中标记，下一步应优先核对边缘缓存规则，而不是先改404页面模板。
条件二：异常不可复现
偶发异常不能靠“再刷几次看看”取证。应保留带时区的请求时间、客户端出口IP或节点区域、完整响应头、以及边缘访问日志中同一时间窗的原始记录。若日志由第三方托管，还要保留日志导出时间和查询条件。结果如何影响下一步：当日志能对齐到同一秒级时间窗，才有条件判断是单节点故障还是规则下发延迟；对不齐时，任何结论都只是猜测。
必须保留的最小证据集
以下材料按优先级排列，缺一项都会削弱可比性。
- 源站原始响应：直接回源请求同一URL的状态码与响应头，确认源站404是真实404，不是被改写成200的软404。
- 边缘响应：同一URL经边缘节点返回的状态码、响应头与响应体片段，注明请求时刻和节点区域。
- 请求标识：边缘请求ID、trace ID或日志中的唯一键，用于把用户侧现象与边缘日志对上。
- 时间线：异常首次出现、持续区间、是否与发布、缓存刷新或证书变更时间重合。
- 影响面样本：若干条404 URL的对照结果，区分“全部404异常”还是“仅部分路径异常”。
这套证据的作用是缩小范围，不是直接给出结论。例如源站404正常、边缘返回502，可能指向回源连接问题；源站404正常、边缘返回200旧内容，可能指向缓存未失效。两者后续动作不同。
规模化后为什么不能照搬单样本结论
个别样本成立，不代表可以推广到全站。单条URL在边缘表现正常，可能只是因为它命中了不同缓存分区、不同节点版本或不同规则集。规模化后出现例外，常见原因是规则分批下发、节点版本不一致，或部分路径被单独配置覆盖。
因此，把单样本结论用于全站前，至少要做两件事：一是按路径类型、缓存策略、节点区域分层抽样，而不是随机多测几条；二是记录每层样本的命中节点与规则版本。若抽样结果显示异常集中在某一节点版本或某一类路径，说明问题在配置层而非页面层，此时修改404页面设计本身不会改变边缘行为。
一个注明假设的短例子
假设某站点源站对/old-page返回404，边缘节点A返回404，节点B返回200并展示旧内容。若只保留节点B的截图，会误判为“404页面被缓存”。若同时保留源站响应头、两个节点的响应头和各自请求ID，就能看出差异在节点而非源站。下一步动作应是核对节点B的缓存规则与刷新记录，而不是重做404页面。这个例子只说明比较方法，不代表任何真实站点结果。
取证时的常见误判
抓取量或请求量下降不能单独证明边缘异常已被处理，它也可能来自抓取预算变化、robots限制或流量自然波动。robots.txt的抓取限制不等于可靠的索引移除；站点地图不保证收录；HTTPS不保证安全无漏洞或排名。这些事实提醒我们，边缘异常的证据要落在响应本身，而不是落在某个统计数字的升降上。
最后，证据保留应设定明确期限和存放位置，确保在缓存刷新、日志轮转或节点重启后仍可复查。若无法保留原始响应，至少保留可复核的请求参数、时间戳和日志查询条件，否则后续只能凭记忆推断，无法支撑任何修复决策。
