404页面灰度只放1%流量，为什么全量后例外集中爆发

📍 WDQWDWQD987AAAAA:216.73.217.58
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /5aebca26ae48.html
📄

404页面灰度只放1%流量，为什么全量后例外集中爆发

因为灰度样本天然偏向高频、结构规整、近期被访问的URL，而全量发布后才会碰到低频、参数复杂、由旧系统或旧合作关系遗留的请求。404页面本身不是问题，问题是这些请求该返回404、410、301还是200，灰度阶段根本没覆盖到。

假设情境：一次只放1%流量的404改造

假设某站点把旧产品目录整体下线，计划把失效URL统一指向新的404页面，并在灰度阶段只让1%的入口流量走新逻辑。灰度期间错误率没有上升，团队据此认为可以全量。这个结论成立的前提是：灰度流量里包含了足够多的“例外请求类型”。如果1%恰好都来自首页、栏目页和近期热门文章，那么旧产品详情页、带跟踪参数的分享链接、合作方深链、站内搜索产生的拼接URL，可能一条都没被抽中。

全量后例外集中爆发，通常不是新逻辑写错了，而是灰度没有覆盖请求分布的长尾。判断依据可以看三组证据：灰度期间命中的URL模板数量、带查询参数的请求占比、以及来自外部引用或旧合作方的入口占比。如果这三项在灰度样本里明显低于日常全量日志，那么“灰度通过”只能说明高频路径没问题，不能说明例外路径已被处理。

先分清：哪些请求应该继续404，哪些不该

全量后要做的第一件事不是回滚，而是把爆发出来的例外分类。分类标准应基于“这个URL是否仍然承载价值”，而不是“它是不是404”。

这个分类动作会直接决定下一步：如果例外主要集中在“应保留200”的旧合作深链，那么要改的是404规则的匹配范围；如果集中在“应做301”的旧内容，那么要补的是映射表，而不是调整404页面本身。

灰度样本要能代表例外，而不是只代表主流

一次能暴露例外的小流量灰度，关键不在流量比例，而在抽样方式。可按下面的顺序调整：

  1. 从近30天访问日志中提取URL模板，而不是抽取具体URL。模板能覆盖参数化请求，例如带?from=、?ref=的分享链接。
  2. 按“高频、低频、外部引用、站内搜索、旧系统回调”分层，每层至少放入灰度。若某一层在灰度中为0，就明确标记为未验证，而不是默认通过。
  3. 灰度期间单独记录404、410、301、200的命中分布，并与全量历史分布对比。差异大的模板，就是全量后的风险点。

这里有一个容易误判的现象：灰度期间404请求量很低，不代表规则正确。它也可能是灰度流量根本没触达那些旧URL。同理，全量后404请求量突然归零，也不能单独证明处理正确，还可能是规则把请求错误地改写成了200，或者抓取程序暂时降低了访问。需要结合响应码分布和入口来源一起看。

一个可执行的回退与放量判断

假设全量后例外请求占比超过预设阈值，且其中大部分属于“应保留200”的旧合作深链。此时合理的动作是：先把404规则的匹配范围收窄到已确认下线的URL模板，保留旧合作路径的原有响应；再重新跑一轮分层灰度，把外部引用和旧系统回调单独作为一层。这个动作的结果是，例外请求不再进入404页面，同时你获得了更接近真实的样本分布，下一轮放量才有依据。

如果例外主要是“应做301”的旧内容，则不要急着回退规则，而是补齐映射表后再放量。映射表补完后，仍要检查跳转目标是否与旧URL主题一致。若目标页只是栏目页或首页，用户仍可能认为内容不存在，抓取程序也可能将其视为软404。

无论哪种情况，都不要用robots.txt的抓取限制来代替索引移除。robots.txt只能阻止抓取，不能保证已收录URL从索引中消失；站点地图也不保证收录。把这两者当作404处理的替代方案，会让例外问题从响应码层面转移到索引层面，更难排查。

放量前需要确认的边界条件

这套判断成立的前提是：你能拿到灰度与全量的请求日志，并且能按URL模板和来源分层。如果日志缺失或只有聚合计数，那么灰度通过的说服力有限，应优先补齐可观测性，而不是直接全量。

另外，404页面改造往往牵涉旧内容、旧系统或旧合作关系的退出。退出不等于全部删除：仍然有价值的旧URL应保留可达路径，明确无价值的才返回404或410。灰度要验证的，正是这条边界是否被规则准确覆盖。全量后例外集中爆发，通常说明边界在灰度样本里没有被画出来，而不是404页面本身出了问题。

图1 图2
nginx