HTTP 重定向基础与设计原则

一次重定向发生了什么

客户端向服务器请求 URL 后，服务器没有直接返回页面内容，而是返回 3xx 状态码和 Location 响应头。客户端读取 Location，再向新地址发起下一次请求。只有获得最终的非重定向响应，完整链路才结束。

GET /old-page HTTP/1.1
Host: example.com

HTTP/1.1 301 Moved Permanently
Location: https://www.example.com/new-page

每多一个节点，就多一次 DNS、连接、TLS 或网络往返机会。浏览器可能复用连接，但重定向仍然增加延迟，也让缓存、Cookie、请求方法和故障诊断更复杂。

跳转链与最终地址

常见的不理想链路是：HTTP 非 www → HTTPS 非 www → HTTPS www → 新路径。四条规则分别正确，组合后却产生三次跳转。更好的做法是让所有旧入口直接指向唯一规范地址。

规范化规则应由谁负责

同一个站点可能在 CDN、负载均衡、Nginx、应用框架和 CMS 插件中都配置重定向。最常见的循环并不是单条规则写错，而是不同层对“正确地址”理解不一致。例如 CDN 强制 HTTPS，应用却因代理头识别错误而认为请求仍是 HTTP，持续跳回 HTTPS。

应给每类规则指定单一责任层：协议和主机名规范化通常放在最外层代理；业务路径迁移由应用或可版本化的规则文件处理；短期活动跳转应设置明确的撤销时间。不要让多个层同时完成同一件事。

绝对地址与相对 Location

Location 可以是完整 URL，也可能是 /new-path、../target 或以 // 开头的协议相对地址。浏览器会根据当前地址解析它们。迁移规则中优先使用明确、可预测的目标，尤其要检查路径、查询参数、端口和大小写是否被保留。

缓存会改变测试结果

301 和 308 可能被浏览器、代理或 CDN 长时间缓存。即使服务器规则已经修改，本地浏览器仍可能直接使用旧目标。因此排障时要结合无缓存请求、本站服务器端检测、CDN 缓存状态和源站日志，不要只依赖一个已使用很久的浏览器标签页。

上线前的最小验收

1. 分别测试 HTTP/HTTPS、www/非 www、带尾斜杠和不带尾斜杠的入口。
2. 确认旧路径直接到达对应新路径，而不是全部落到首页。
3. 检查最终状态、总耗时、证书域名和所有 Location。
4. 确认不存在协议降级、域名往返或查询参数意外丢失。
5. 从真实用户地区和搜索引擎可访问网络进行复测。