301转向测试环境与线上怎样对照：用同一份验收表核对跳转链

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

301转向测试环境与线上怎样对照：用同一份验收表核对跳转链

301转向在测试环境和线上的对照，核心不是看两个环境“像不像”，而是用同一份检查表分别记录请求与响应，再逐项比对差异。测试环境用来验证规则是否写对，线上用来确认实际生效结果；两者只要在跳转链、状态码、目标地址、参数保留和协议主机名上出现任何一项不一致，就不能直接上线。

先确定对照的交付结果

开始测试前，先明确这次301转向要交付什么：哪些旧地址需要跳转、跳到哪个新地址、是否保留查询参数、是否统一到HTTPS和主域名、是否存在多级跳转。把这些写成一张验收表，测试环境和线上都按同一张表逐行填写。没有这张表，两边只是各测各的，无法对照。

验收表至少包含五列：请求地址、预期状态码、预期目标地址、实际状态码、实际目标地址。测试环境和线上各填一份，差异行就是需要处理的问题。

用命令行获取可对照的原始响应

浏览器地址栏会自动跟随跳转，看不到中间过程，所以两边都要用能显示完整跳转链的方式抓取。例如在命令行中请求一个旧地址，观察每一跳的状态码和Location头：

curl -I -L --max-redirs 5 http://example.com/old-page

假设测试环境返回301到新路径，线上却返回302或直接200，这就是典型的不一致。302是临时跳转，搜索引擎对它的权重传递处理与301不同；200则说明跳转根本没生效。注意这里要区分“可能原因”和“已定位原因”：返回302可能是规则写成了临时跳转，也可能是中间层重写覆盖，需要继续查配置才能确认，不能只看状态码就下结论。

测试环境与线上允许不同的部分

两个环境的域名和主机名通常不同，这是正常的。对照时要把“环境差异”和“规则差异”分开：

判断方法：把测试环境的响应地址中的测试域名替换成正式域名，再与线上实际响应比对。替换后仍不一致的，才是规则本身的问题。

重点检查四类容易漏掉的差异

  1. 跳转层级：测试环境一跳到位，线上可能因为CDN、反向代理或旧规则叠加变成两跳甚至三跳。多级跳转会增加延迟，也可能在中间某一跳丢失参数。用上面的命令数一数实际跳了几次。
  2. 查询参数：带参数的旧地址（如/old?a=1）跳转后参数是否保留，两边要一致。如果测试环境保留、线上丢弃，用户和统计都会受影响。
  3. 协议与主机名：HTTP到HTTPS、带www到不带www的跳转，两边规则要对应。测试环境如果没有配置HTTPS，可以只核对跳转目标，但要注明这一项未在测试环境验证。
  4. 大小写与尾斜杠：/Old-Page和/old-page、带斜杠和不带斜杠，是否都按预期跳转，两边要逐条测，不能只测一个代表。

上线前的验收与上线后的复核

测试环境全部通过后，上线时按验收表逐条请求线上地址，记录实际状态码和目标地址。发现差异先判断是配置未生效、缓存未刷新，还是规则本身写错。缓存问题可以稍后重试，规则问题必须回退修改。

上线后还要复核两点：一是旧地址是否仍然可访问并正确跳转，二是新地址本身是否返回200而不是也参与跳转。如果新地址又被另一条规则跳走，就会形成跳转链甚至循环，用命令时看到--max-redirs次数用尽仍未到达终点，就说明存在循环或过长跳转链。

下一步：把上面五列验收表复制成两份，一份填测试环境、一份填线上，只处理两边不一致的行；全部一致后再检查一次线上旧地址的实际响应。

图1 图2
nginx