HTTP状态码404：源站正常而边缘节点异常时应保留哪些证据
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /e35a1b0252ca.html
📄
HTTP状态码404：源站正常而边缘节点异常时应保留哪些证据
先给出结论：当源站对同一路径稳定返回200或正常业务响应，而边缘节点返回404时，你要保留的不是一句“边缘有问题”，而是一组能证明差异边界的证据——同一时刻的请求标识、源站与边缘的响应头、缓存命中状态、节点分布和复现条件。只有这些证据能让你判断问题是缓存键、回源路径、路由规则还是节点局部故障，进而决定下一步是清缓存、改规则还是回滚配置。
先分清两种404：源站缺失与边缘改写
源站正常而边缘异常，本质是同一资源在两处得到不同判定。源站404意味着资源确实不存在或应用路由未匹配；边缘404则可能是边缘在没有正确回源、回源被拒、缓存了旧的404，或把请求路由到了错误的上游。两者处理方向完全不同，所以证据的第一层任务就是证明“源站当时是什么状态”。
可操作的起点是：固定一个已知在源站存在的URL，同时向源站直连地址和边缘入口发起请求，记录时间、请求ID、响应状态、响应头和响应体长度。如果源站返回200而边缘返回404，且两者响应头中的缓存标识、回源标识不同，就说明差异发生在边缘层。若源站也返回404，则应回到应用或文件本身排查，不属于本篇场景。
必须保留的证据清单
证据要能回答“谁在什么条件下返回了404”，而不是只留下一个截图。以下项目建议逐条记录，缺一项都可能让后续判断失去对照。
- 请求侧标识：完整URL、查询字符串、请求方法、Host头、客户端IP归属地、时间戳（精确到秒或毫秒）。
- 响应侧状态：边缘返回的状态码、响应头中的缓存状态（如命中、回源、过期）、回源响应码、边缘节点标识或机房代号。
- 源站侧对照：同一时刻源站直连返回的状态码、响应头、响应体摘要，以及应用日志中对应的请求记录。
- 复现条件：是否只在特定地区、特定运营商、特定节点、特定UA或特定查询参数下出现；换一个节点或换一个时间点是否仍复现。
- 变更记录：最近对缓存规则、回源配置、路由规则、证书或WAF策略的改动时间和内容，以及改动前后的行为差异。
这些证据的作用是建立对照：如果边缘404只在某几个节点出现，而源站始终200，问题更可能是节点局部状态或节点缓存；如果所有边缘节点都404而源站200，则更可能是全局回源配置或缓存键规则被改坏。
用一组对照请求锁定边界
假设一个页面在源站返回200，边缘返回404。你可以设计三组对照请求，每组只改变一个变量：
- 同一URL，分别请求源站直连和边缘入口，比较状态码与响应头。
- 同一URL，分别带查询参数和不带查询参数，观察边缘是否因缓存键不同而回源或命中旧404。
- 同一URL，从两个不同地区的节点请求，观察是否只有部分节点异常。
如果带参数时边缘回源并返回200，不带参数时命中缓存404，那么证据指向缓存键或缓存内容问题，下一步应检查该URL的缓存记录和清除范围，而不是直接改源站。如果两个节点都404且响应头显示未回源，则更可能是边缘路由或回源策略问题，下一步应核对回源地址和回源Host配置。
证据如何影响下一步动作
证据的价值在于缩小动作范围。以下对应关系可以作为决策依据，但每一条都需以实际响应头和应用日志为准，不能只凭状态码猜测。
- 若边缘响应头显示缓存命中且缓存时间为404，源站为200，优先处理该URL的缓存清除，并确认清除后是否回源成功。
- 若边缘响应头显示回源失败或回源超时，源站日志无对应请求，优先检查回源链路、回源地址和防火墙策略。
- 若只有部分节点异常，源站和多数节点正常，优先隔离异常节点并对比其配置版本，而不是全量回滚。
- 若所有节点同时异常且源站正常，优先核对最近一次全局配置变更，并准备回滚方案。
执行一次动作后，必须用同一组对照请求复测并记录新结果。如果清除缓存后边缘恢复200，说明缓存内容或缓存键是直接原因；如果清除后仍404，则缓存假设被削弱，应转向回源和路由证据。这个“动作—复测—修正假设”的循环，比一次性收集大量无关日志更有效。
规模化后不能照搬的边界
单个样本成立不代表批量处理成立。一个URL在边缘返回404，可能只是该URL的缓存记录异常；当你把同样的清除或改规则动作套用到成千上万个URL时，可能触发回源压力、缓存击穿或误改正常404页面。因此，在规模化前要先确认三件事：异常是否集中在同一类缓存键或同一批节点；源站能否承受批量回源的瞬时压力；批量动作是否会覆盖那些本来就应返回404的已删除页面。
另外，边缘404与源站404的日志口径可能不同，抓取量或请求量的下降不能单独证明处理正确，也可能是抓取节奏变化、robots.txt限制或统计口径调整。要判断影响是否消除，应回到同一组对照请求和源站应用日志，而不是只看某个总量指标。
最后，把证据按“请求—边缘响应—源站响应—变更记录”归档，并注明采集时间和复现条件。这样即使问题再次出现，也能快速判断是同一原因复发还是新变更引入，避免每次从零排查。
