404notfound：错误只在特定时段出现时怎样捕捉短暂证据，先区分三种“特定时段”，再决定保留什么
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /796411fa0757.html
📄
404notfound：错误只在特定时段出现时怎样捕捉短暂证据，先区分三种“特定时段”，再决定保留什么
最有效的做法不是守着浏览器刷新，而是把“出现时间、请求特征、响应头、服务端日志”四类证据同时留档，让一次复现变成可复核的事件记录。若错误只在夜间或流量高峰出现，优先保留原始日志并打时间戳，再决定是保留、改写还是退出当前排查路径。
先区分三种“特定时段”，再决定保留什么
时段规律不同，证据的保存重点也不同。先判断属于哪一类，能避免把偶发现象当成稳定故障。
- 固定时间窗：例如每天凌晨任务执行时出现。重点保留任务起止时间、同一时刻的访问日志和缓存刷新记录。
- 负载相关：例如访问量上升后出现。重点保留并发数、响应耗时、后端超时或连接被重置的日志。
- 外部触发：例如某个上游系统定时调用或缓存过期后出现。重点保留请求来源、请求路径和响应头中的缓存状态。
如果三类特征混在一起，先按时间戳对齐日志，再按请求路径分组。分组之后仍无法区分，说明证据粒度不够，下一步应增加记录字段，而不是继续猜测原因。
用最小留档动作把短暂错误变成可核对记录
假设某路径只在每天 02:00 到 02:10 返回 404，其他时段正常。可以做一个最小留档：在服务端日志中记录请求时间、完整路径、查询字符串、User-Agent、Referer、响应状态和响应耗时；同时保留该时段应用日志与反向代理日志。
动作结果是：如果 404 只出现在代理日志而不出现在应用日志，说明请求可能没有到达应用层，后续应检查代理规则或上游转发；如果两层日志都有相同路径的 404，则更可能是应用路由或内容状态在特定时段发生变化。这个结果直接决定下一步是查转发链路，还是查应用侧的内容与路由。
留档时注意：日志时间要统一时区，并记录服务器时间与标准时间的偏差。否则跨系统对齐时会凭空多出或缺少几分钟，足以让短暂错误看起来像另一个时段的问题。
保留、改写还是退出：三种取舍的适用前提
保留适用于错误仍可能复现、且当前证据能支撑继续观察。此时不要急着改配置，先扩大留档范围，例如增加请求头、响应头和上游返回码。保留的代价是排查周期变长，但能避免在证据不足时误改规则。
改写适用于已经能稳定复现，并且定位到具体规则。例如确认是某条重写规则在特定时段被缓存刷新触发。改写前先导出当前规则和一份失败请求样本，改写后立即用同一路径在同一时段验证。若改写后错误消失但其他路径出现异常，说明影响面被转移，应回退并重新评估。
退出适用于错误无法复现、且现有证据表明它不影响主要访问路径。退出的前提是留下退出理由和观察窗口，例如继续监测一周内同一时段的日志。退出不等于删除证据，原始日志仍应保留到可复核为止。
避免把“归零”当成处理正确的证明
某时段 404 数量降为零，可能有多种解释：错误确实被修复；日志采样或保留策略变化导致记录缺失；请求被更早的规则拦截，状态码不再显示为 404；或者该时段的访问本身减少。归零只能说明当前观测结果变化，不能单独证明处理正确。
要区分这些解释，可以对比同一时段的请求总量、其他状态码分布和上游调用量。如果请求总量同步下降，更可能是访问减少；如果请求总量稳定而 404 消失，才更接近规则或内容被修正。这个对比结果决定下一步是结束观察，还是继续保留留档。
把分歧转成下一次可核对的记录
当运维、开发和内容负责人对同一现象有不同理解时，不要争论“到底是不是 404”，而是把分歧写成可核对的条目：谁在什么时间、用什么路径、看到什么状态码、对应哪份日志。每条记录注明来源和假设，例如“假设该请求经过代理层”。
下一次错误出现时，用同一张记录表逐项填写。若某项始终无法填写，说明该证据在当前链路中不可得，应调整留档位置或增加记录点。这样做的结果是：排查不再依赖个人记忆，而是依赖一份可复查的时间线，保留、改写或退出的决定也都有据可依。
