HTTPS 重定向陷阱：301、302 与 HSTS 的优先级和缓存问题

在将网站迁移到 HTTPS 的过程中，重定向是最基础也最容易出错的环节。许多运维人员认为只要在服务器配置里加一行 return 301 https://... 就万事大吉，但实际场景中，301、302 与 HSTS 之间的优先级冲突、浏览器缓存行为差异，常常导致难以排查的诡异问题。本文将从协议层面拆解这些陷阱，并给出可落地的排查与配置建议。

一、301 与 302：不只是“永久”和“临时”的区别

HTTP 状态码 301（Moved Permanently）和 302（Found）在语义上的区别广为人知，但它们在 HTTPS 重定向场景中的行为差异远不止于此。

1.1 浏览器缓存策略截然不同

301 响应默认会被浏览器长期缓存。 一旦浏览器收到 301，它可能将重定向关系写入磁盘缓存，有效期由响应头中的 Cache-Control 和 Expires 决定；若未显式设置，Chrome、Firefox 等主流浏览器会采用启发式缓存，时间可能长达数天甚至数月。

302 响应默认不被长期缓存。 浏览器通常只在当前会话内保留 302 重定向，关闭标签页或重启浏览器后即失效。

这意味着：如果你在生产环境误用 301 做临时跳转，用户浏览器可能被“锁死”在旧地址上，即使你后来修正了服务器配置，用户仍然会被缓存的重定向带到错误的目的地。

1.2 对 SEO 的影响

301 会将原 URL 的权重传递给目标 URL，适合永久迁移；302 则不传递权重，适合临时维护或 A/B 测试。在 HTTPS 迁移中，如果只是短期调试，使用 302 更安全；确认迁移完成后，再切换为 301。

1.3 实战建议

• 调试阶段一律使用 302，确认无误后再改为 301。
• 如果必须使用 301，务必在响应头中显式设置较短的 Cache-Control: max-age=3600，为纠错留出窗口。
• 已经误发 301 时，可通过 Clear-Site-Data: "cache" 响应头（需 HTTPS）尝试清除浏览器缓存，但支持度有限，最可靠的方式仍是引导用户手动清除或更换域名。

二、HSTS：比 301 更“顽固”的重定向

HSTS（HTTP Strict Transport Security）通过响应头 Strict-Transport-Security 告诉浏览器：在指定时间内，对该域名的所有请求必须使用 HTTPS，即使用户输入的是 http://。

2.1 HSTS 的优先级高于 HTTP 重定向

关键点在于：HSTS 在浏览器发出 HTTP 请求之前就已经生效。 当浏览器记录了某个域名的 HSTS 策略后，它会在内部将 http://example.com 直接改写为 https://example.com，根本不会发出明文 HTTP 请求。因此，服务器端的 301/302 重定向在这个场景下完全不会被触发。

这带来一个隐蔽的陷阱：如果你在服务器上配置了 http:// 到 https:// 的 301，同时又在 HTTPS 响应中启用了 HSTS，那么对于已经记录 HSTS 的浏览器，301 规则形同虚设；而对于尚未记录 HSTS 的浏览器，301 仍然生效。这种“部分用户走 HSTS、部分用户走 301”的分裂状态，会让问题排查变得非常困难。

2.2 HSTS 的缓存不可逆性

HSTS 的 max-age 由服务器指定，一旦浏览器记录，在有效期内无法通过服务器端撤销。即使你删除了 Strict-Transport-Security 响应头，浏览器仍会在 max-age 到期前继续强制 HTTPS。

更严重的是，如果将 max-age 设置得很大（如 max-age=31536000，即一年），而证书出现问题时，用户将完全无法访问网站，因为浏览器拒绝降级到 HTTP。

2.3 实战建议

• 首次启用 HSTS 时使用较小的 max-age（如 max-age=300），确认 HTTPS 全站可用后再逐步增大。
• 使用 includeSubDomains 前，确保所有子域名都已支持 HTTPS，否则子域名将无法访问。
• 考虑提交到 HSTS Preload 列表前，务必确认已满足所有前提条件，因为 Preload 的撤销周期极长。

三、优先级冲突：当 301、302 与 HSTS 同时存在

在实际生产环境中，三者可能同时存在，其优先级顺序如下：

1. HSTS（浏览器内部）：最高优先级，直接改写请求协议。
2. 301/302（服务器端）：在 HSTS 未生效时起作用。
3. HTML meta refresh 或 JavaScript 跳转：最低优先级，且对 SEO 不友好。

一个典型的冲突场景是：服务器配置了 http:// → https:// 的 301，同时 HTTPS 响应中带有 HSTS 头。对于新用户，第一次访问 http:// 时，浏览器发出明文请求，服务器返回 301，浏览器跳转到 HTTPS，然后收到 HSTS 头并记录。从第二次访问开始，浏览器直接走 HTTPS，301 不再被触发。

如果此时你修改了 301 的目标地址（例如从 https://example.com 改为 https://www.example.com），已记录 HSTS 的用户会直接访问 https://example.com，完全绕过你的 301 规则，导致他们仍然停留在旧地址上。

四、排查与配置清单

面对 HTTPS 重定向问题，建议按以下步骤排查：

1. 检查 HSTS 状态：在 Chrome 中访问 chrome://net-internals/#hsts，查询域名是否在 HSTS 列表中。
2. 检查 301 缓存：使用 curl -I 查看响应头，确认 Cache-Control 和 Location 是否符合预期。
3. 使用无痕窗口测试：无痕窗口不携带 HSTS 记录和 301 缓存，可模拟新用户行为。
4. 清理测试环境：在 chrome://net-internals/#hsts 中删除域名策略，在开发者工具中勾选“Disable cache”并清除浏览器缓存。

推荐配置模板：

# HTTP 服务器块：仅用于重定向和 ACME 挑战
server {
    listen 80;
    server_name example.com www.example.com;

    location /.well-known/acme-challenge/ {
        root /var/www/certbot;
    }

    location / {
        return 301 https://www.example.com$request_uri;
    }
}

# HTTPS 服务器块
server {
    listen 443 ssl http2;
    server_name www.example.com;

    # 证书配置...
    add_header Strict-Transport-Security "max-age=300" always;

    # 业务逻辑...
}

注意：在 HSTS 的 max-age 调大之前，保持 301 重定向的 Cache-Control 较短，以便在配置调整时能够快速生效。

五、总结

HTTPS 重定向看似简单，实则涉及浏览器缓存、HSTS 预加载、SEO 权重传递等多个层面的交互。核心原则有三条：

• 调试用 302，稳定用 301，并控制缓存时间。
• HSTS 是“不可逆”的加速器，启用时从短 max-age 开始。
• 三者优先级中，HSTS 最高，301/302 次之，务必在无痕模式下验证真实用户路径。

只有理解这些机制之间的优先级和缓存行为，才能避免“配置改了但用户仍被带到旧地址”这类令人头疼的问题。

未经允许不得转载：任鹏个人博客 » HTTPS 重定向陷阱：301、302 与 HSTS 的优先级和缓存问题