301转向，一次小流量灰度如何暴露全量发布的例外

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

301转向，一次小流量灰度如何暴露全量发布的例外

灰度发布能提前暴露 301 转向的问题，但前提是灰度样本必须覆盖真实流量结构。如果灰度只挑了旧页面访问、未覆盖带参数、尾斜杠、大小写、移动端 UA 或外链落地页，那么全量发布后出现的例外，并不是灰度失败，而是灰度范围本身有盲区。判断是否该扩大灰度、分批全量还是回滚，取决于例外是否击中核心入口、是否可复现，以及修复后能否在不改变 URL 语义的前提下收敛。

先定义灰度样本要覆盖哪些请求

把灰度理解为“随机放 5% 流量”通常不够。301 转向的例外往往集中在少数请求形态上，随机抽样反而容易漏掉。更可靠的做法是按请求特征分层，每层都留出可观测样本。

假设一次灰度只放行首页和栏目页，那么全量时最先出问题的往往是详情页或带参数的活动页。这不是运气，而是样本没有覆盖到这些请求。灰度前先列出业务上不可丢失的入口清单，再按清单分配样本，比单纯追求比例更有意义。

灰度期间要采集哪几类证据

301 转向是否生效，不能只看浏览器地址栏。至少同时记录以下证据，才能区分“转向正确”“转向正确但抓取异常”“转向根本没执行”三种情况。

  1. 响应状态码与 Location 头：确认返回的是 301 还是 302、307，以及目标地址是否完整。
  2. 目标页最终状态：目标页是否返回 200，是否又发生二次跳转。
  3. 请求日志：同一路径在灰度组与对照组是否得到不同处理。
  4. 抓取记录：爬虫是否仍在请求旧地址，是否出现抓取量骤降。

抓取量下降或某路径请求归零，不能单独证明 301 处理正确。它也可能来自 robots.txt 限制、站点地图未更新、服务器临时故障或爬虫调度变化。robots.txt 的抓取限制不等于可靠的索引移除，站点地图也不保证收录，因此证据要交叉看，而不是用单一指标下结论。

例外出现时，先判断它属于哪一类

全量发布后暴露的例外，通常落在三类里，处理方式不同。

第一类：规则未覆盖

旧路径不在转向映射表中，或映射表只匹配了精确路径，未匹配带参数版本。特征是例外可稳定复现，且集中在特定 URL 形态。此时应补充规则并重新灰度，而不是直接回滚全部改动。

第二类：规则冲突

多条规则同时命中同一请求，或 CDN、反向代理、应用层各有一套转向，导致最终 Location 与预期不一致。特征是同一 URL 在不同网络环境下结果不同。此时要先确定唯一权威层，其余层只做透传。

第三类：目标页自身有问题

301 本身正确，但目标页返回 404、500 或又跳回旧地址，形成循环。特征是 Location 正确而最终状态异常。此时应修目标页，而不是继续改转向规则。

区分这三类，决定下一步是补规则、收敛层级还是修目标页。若把第三类误判为第一类，会不断加规则却始终无法收敛。

用一个小例子说明决策边界

假设某站点有 2000 个旧详情页需要转向新详情页，灰度只选了其中 50 个无参数页面。全量后发现带 ?from= 的旧链接没有转向，直接落到 404。此时可复现、集中、且不影响无参数页面。

合理动作是：先确认这些带参数链接是否有真实外链和站内入口；若有，补一条忽略查询参数的匹配规则，再对这批 URL 单独灰度；确认响应状态码与 Location 稳定后，再全量。若这些链接本就无入口、无外链，也可以选择不转向，让它们自然失效，但要在监控中保留观察，避免后续误判。

这个动作的结果会直接影响下一步：补规则后例外消失，说明问题属于规则未覆盖，可以继续全量；补规则后仍出现不同 Location，说明存在层级冲突，应转向排查 CDN 与源站配置；若 Location 正确但目标页异常，则应暂停转向发布，先修目标页。

全量前需要满足的条件

灰度通过不等于可以全量。全量前至少确认：核心入口清单中的 URL 形态都已覆盖；例外分类已有明确归属；回滚路径可用且不会造成二次跳转；监控能区分 301、302 与目标页错误。HTTPS 不保证安全无漏洞或排名，不同搜索引擎对转向信号的支持情况也需分别核查，因此不要把“已启用 HTTPS”当作转向正确的依据。

如果灰度样本无法覆盖核心入口，宁可扩大灰度范围或延长观察，也不要用“比例够了”作为全量理由。301 转向的风险不在比例，而在例外是否恰好落在不可丢失的入口上。

图1 图2
nginx