URL重定向：测试环境与线上怎样对照
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /29eddb545143.html
📄
URL重定向：测试环境与线上怎样对照
对照测试环境与线上的 URL 重定向，关键是让两端对同一个旧 URL 发出请求，再比较状态码、Location 响应头和最终落地 URL 是否一致。不能只看浏览器地址栏，因为缓存、前端路由和登录跳转都可能掩盖真实的重定向行为。
先固定一组可对照的 URL 样本
从线上已经存在的旧地址里挑选样本，覆盖不同情况：一条普通内容页、一条带结尾斜杠的地址、一条带查询参数的地址、一条曾经改过栏目的地址。把这份清单同时用于测试环境和线上，不要临时凭记忆输入。
如果测试环境的域名与线上不同，需要先确认测试环境里已经配置了与线上相同的重定向规则。否则两边请求的根本不是同一套配置，对照没有意义。可以先在测试环境访问一个已知应当跳转的地址，确认规则确实生效。
用状态码和 Location 做逐项比对
不要只凭肉眼观察页面跳到了哪里。用命令行工具查看响应头，例如：
curl -I https://example.com/old-page
重点看三项：第一行返回的状态码，Location 响应头指向的目标，以及最终页面返回的状态码。常见的对照结果有这几种：
- 两端都返回 301，且 Location 完全一致：规则一致，可以继续抽查其他样本。
- 测试环境返回 301，线上返回 302：跳转方向可能相同，但跳转类型不同，需要确认线上是否漏配了永久重定向。
- 一端返回 301，另一端返回 200：说明有一端没有触发重定向，旧地址被直接当成了正常页面。
- 两端状态码相同，但 Location 指向不同路径：目标配置存在差异，要核对目标 URL 的拼接规则。
如果测试环境带端口或子目录，Location 里出现测试域名属于正常现象；此时应比较路径部分是否一致，而不是要求完整 URL 逐字相同。判断标准是：把测试域名替换为线上域名后，路径和参数能否对得上。
处理对照中发现的差异
发现差异后，先定位差异出现在哪一层。可能的原因包括：测试环境的规则文件没有同步、线上使用了额外的服务器配置、缓存仍在返回旧响应、目标地址本身在两端部署的路径不同。
处理顺序建议从配置入手，而不是先清缓存。确认两端的重定向规则来源是否一致，再检查是否存在多条规则命中同一个旧地址。多条规则叠加时，先命中的那条决定结果，后配置的规则可能永远不会执行。
修改后不要立刻下结论。重定向可能被浏览器或中间层缓存，测试时加上禁用缓存的参数，或换一个此前没有请求过的地址验证。301 被缓存后，短时间内可能仍然看到旧结果，这不代表配置没改成功。
复查时确认跳转链和落地页
复查不只看第一步跳转，还要确认整条链是否干净。理想情况是一次跳转到达最终地址，而不是旧地址跳到中间地址、再跳到另一个地址。跳转链过长会增加不确定因素，也不利于后续维护。
同时检查最终落地页是否返回 200，内容是否与旧地址主题相关。如果落地页本身又发生跳转或返回 404，说明目标配置有问题，需要回到上一步调整。
对照完成后，保留一份记录：样本 URL、两端状态码、Location 目标、复查时间。下次规则变动时，用同一份样本重新跑一遍，就能快速判断是否引入了新的差异。
下一步可以做的具体动作是：从线上导出最近改版涉及的旧 URL 列表，按上面的四类各选几条，分别在测试环境和线上执行 curl -I，把结果并排记录，再逐条处理不一致的项。
