404错误排查：一次小流量灰度如何暴露全量发布的例外
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /e366dc8de58f.html
📄
404错误排查：一次小流量灰度如何暴露全量发布的例外
灰度流量只覆盖部分入口，因此它验证的是“常见路径不出404”，而不是“所有路径都不出404”。当灰度期间404率没有明显上升，却在上线后出现集中404，通常说明例外路径没有被灰度样本命中。排查动作应转为对比灰度与全量的请求集合，而不是继续盯着404总量。
假设情境：灰度只测了首页和栏目页
假设一个内容站改版，把文章路径从/post/123调整为/article/123。灰度只对首页、栏目页和少量随机文章放量，监测显示404数量与改版前接近。团队据此判断重定向规则完整，随后全量发布。上线后，来自站内搜索、旧版RSS和外部收藏的请求开始集中返回404。这个例子里，灰度没有错，错在把灰度结果当成了全量结论。
灰度与全量的差异不在流量大小，而在请求集合
灰度通常按用户、IP或URL比例切分流量。如果切分维度恰好避开了带参数的旧链接、分页链接或大小写变体，灰度期间就不会触发这些路径的404。全量发布后，这些请求重新进入，问题才显现。可执行的最小动作是：从访问日志中分别抽取灰度窗口和全量窗口的请求路径，按路径模式归类，而不是只看404总数。
- 灰度窗口内未出现的路径模式，不能推断为“无问题”，只能标记为“未覆盖”。
- 全量后新增的404若集中在某类模式，优先检查该类模式是否被重定向规则遗漏。
- 404总量下降也可能来自抓取量减少或日志采样变化，不能单独作为修复成功的证据。
缺少完整日志时，仍可做的最小验证
如果没有全量日志权限，可以退一步：用站点地图中的URL样本、内链抽取结果和已知的外部入口各取一批链接，直接请求并记录状态码。这个动作不能证明全站无404，但能区分“规则整体失效”和“少数模式遗漏”。例如，若站点地图样本全部返回200，而带?from=rss的样本返回404，则问题更可能出在参数处理或重定向条件上，而不是整条规则链断裂。
需要说明的是，站点地图不保证收录，也不代表其中URL一定可访问；它只是可用的URL样本来源之一。robots.txt的抓取限制同样不等于可靠的索引移除，这两件事与404排查的结论边界不同，不能混用。
从一次例外反推发布检查项
假设验证发现，遗漏集中在带查询参数的旧文章链接。下一步不是立刻全站回退，而是先补一条针对该模式的规则，再用同样的小样本重新请求，观察返回码是否从404变为301或200。如果样本通过，再扩大样本量；如果仍失败，说明重定向条件写错了，而不是灰度策略本身有问题。
- 记录灰度覆盖的路径模式与未覆盖的路径模式。
- 对未覆盖模式取最小样本，逐条请求并记录状态码。
- 只针对失败模式修改规则，避免同时改动无关路径。
- 用同一批样本复测，确认变化来自规则而非缓存或临时网络错误。
灰度结果能推出什么，不能推出什么
灰度能推出的是：在它覆盖的请求集合内，404没有异常增加。它不能推出全量请求集合同样安全，也不能推出重定向规则覆盖了所有历史链接形式。若灰度后404率归零，还需要考虑抓取量下降、日志延迟或监控口径变化等合理解释，不能直接判定处理正确。把灰度当作缩小范围的证据，而不是全量结论，才能在下一次发布前补上例外路径的检查。
