301重定向设置：测试环境与线上怎样对照
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /73d49785a218.html
📄
301重定向设置：测试环境与线上怎样对照
最可靠的做法是：把测试环境当作“规则验证场”，把线上当作“结果验证场”。先在测试环境确认重定向规则本身正确，再在线上用同样的请求路径复核响应状态码、Location 头和最终落地页。两边都通过，才算交付完成；只在一侧通过，就不能合并或上线。
先分清两个环境各自要验证什么
测试环境和线上的差别不只是域名。测试环境通常有访问限制、缓存策略不同、CDN 未接入，线上则可能经过负载均衡、CDN、WAF 等多层处理。因此对照的重点不是“两边页面长得一样”，而是同一组旧 URL 在两边的响应行为是否一致。
- 测试环境验证：规则语法、匹配顺序、目标地址拼接、是否误伤正常页面。
- 线上验证：真实请求经过全部网络层后，返回的状态码和最终落地页是否符合预期。
- 两边都要看：单跳还是多跳、是否出现重定向循环、参数是否保留。
用同一份 URL 清单做对照
多人协作时返工最多的原因，是每个人随手挑几个链接测，结论无法对齐。建议先产出一份固定的对照清单，两边跑同一份。
- 从旧站日志、站点地图或内容后台导出待迁移的 URL，去重后取全量或按类型抽样。
- 每条记录至少包含：旧 URL、期望状态码、期望目标 URL、是否保留查询参数。
- 测试环境和线上各跑一遍，把实际结果填进同一张表。
- 逐行比对，只标记“实际与期望不符”的行，作为待修项。
清单里要覆盖边界情况：带尾斜杠与不带尾斜杠、带查询参数、大小写不同的路径、已不存在的深层页面。这些往往才是规则写错的地方。
看响应头，而不是只看浏览器地址栏
浏览器会自动跟随跳转，地址栏显示的是最终页面，中间的 301 可能被隐藏。判断依据应该是响应头。用命令行请求时只看第一跳：
curl -I https://example.com/old-page
重点看三处：状态码是否为 301；Location 是否指向预期目标；跳转是否只发生一次。如果返回 302、307 或 200，说明规则没生效或被其他规则覆盖。如果连续多次 301 才到终点，属于跳转链，应尽量压缩为一跳。
测试环境如果加了访问认证，curl 可能先拿到登录页而不是重定向结果，这时需要带上访问凭据，或临时对测试请求放行，否则测出来的状态码没有参考价值。
处理两边结果不一致的常见原因
同一份规则在测试环境通过、线上不通过，可能原因有几类，需要逐项排查，不要直接断定是某一层的问题。
- 规则未部署或缓存未刷新：线上仍在使用旧配置，或 CDN 缓存了旧的跳转结果。
- 匹配顺序不同：多条规则同时命中时，先匹配到的生效。两边的规则顺序若不一致，结果就会不同。
- 中间层改写：CDN、负载均衡或 WAF 可能先做了一次跳转，导致最终状态码与源站配置不符。
- 域名与协议差异：测试环境用 http，线上已强制 https，规则里写死的目标协议可能不适用。
- 参数处理差异：一边保留查询参数，一边丢弃，落地页内容就会不同。
定位方法是从最靠近源站的一层开始，逐层向外请求，看状态码在哪一层发生变化。已经定位到的原因和“可能原因”要分开记录，避免把猜测当成结论写进交付文档。
上线前后的复查动作
规则合并到线上后，不要只看首页。按对照清单再跑一遍全量或抽样，确认每条旧 URL 都返回预期状态码并落到正确页面。同时检查反向情况：原本正常的页面是否被误跳转。
如果旧 URL 数量大，可以写一个简单脚本批量请求并输出状态码与 Location，再和清单比对。这类脚本只做检查，不修改线上配置。复查通过后，把对照表、实际结果和未解决项一起归档，作为本次交付的凭据。
下一步：拿一份现有的旧 URL 清单，在测试环境和线上各跑一遍，把不一致的行单独列出来，先修规则再重新对照。
