nginx全站启用http/2后，301重定向高效关键在于：80端口server块顶层用return 301跳转至https，443端口server块必须配置listen 443 ssl http2并启用hsts，避免多级跳转和代理协议误判。
全站启用 HTTP/2 后，Nginx 的 301 重定向本身不受协议版本影响，但要确保重定向链路依然高效，关键在于避免因配置叠加、逻辑嵌套或协议感知错位引入额外延迟。HTTP/2 的多路复用和头部压缩优势，只有在请求真正抵达目标 server 块并完成响应时才能发挥；若重定向过程绕不开低效判断或冗余跳转，HTTP/2 就无从优化。
把 return 301 放在独立的 80 端口 server 块顶层
HTTP/2 只在 TLS 连接（即 443 端口）上启用，80 端口始终运行 HTTP/1.1。因此，HTTP → HTTPS 的跳转必须由纯 HTTP 的 server 块完成，且不能混入任何 rewrite、if 嵌套或 location 匹配逻辑：
- 用
listen 80;单独定义一个轻量 server 块，仅含server_name和return 301 https://$host$request_uri; - 不要在该块中写
ssl on、ssl_certificate或任何 proxy_pass —— 这些会导致启动失败或行为异常 - 确保这条
return指令位于server { }内最靠前位置，早于所有 location 块，跳过后续解析开销
HTTPS server 必须启用 http2，且 HSTS 配置到位
用户跳转后的首次 HTTPS 请求，才是 HTTP/2 发挥作用的起点。若 443 server 块未启用 http2，或缺少 HSTS 头，会削弱链路整体效率：
- 监听行必须为：
listen 443 ssl http2;（不是listen 443 ssl;） - HSTS 响应头需带
always参数，确保浏览器后续请求直接走 HTTPS，跳过明文试探：add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always; - 证书路径正确、私钥权限为
600，否则 Nginx 启动失败或握手超时，导致重定向后连接中断
避免多级跳转破坏 HTTP/2 的首屏收益
HTTP/2 的连接复用和头部压缩对单次 TCP 连接友好，但无法跨跳转生效。一次“HTTP → HTTPS → www → /new-path”链式跳转，等于三次独立请求，完全抵消 HTTP/2 优势：
- 合并逻辑：如需同时规范协议 + 子域，用单条 return 实现，例如：
return 301 https://www.example.com$request_uri; - 禁用中间层 if 判断：不要在 443 server 中再写
if ($host = example.com) { return 301 ... }，这会让本该一次完成的跳转变成两次（80→443→443） - 检查响应头中的
Location字段，确认无重复跳转、无多余斜杠、无协议降级
代理环境下透传 X-Forwarded-Proto，防止后端误判协议
若前端有 CDN 或负载均衡器（如 Cloudflare、ALB），它们可能终止 TLS 并以 HTTP 向 Nginx 转发。此时 Nginx 若只看 $scheme，会误认为仍是 HTTP，导致循环重定向或混合内容警告：
- 一级代理（CDN）需设置
X-Forwarded-Proto: https - Nginx 配置中添加：
set $real_scheme $http_x_forwarded_proto;，并在跳转逻辑中使用$real_scheme判断 - 更稳妥做法是：在 80 server 块中不依赖 scheme 判断，只做无条件跳转；在 443 server 中信任
X-Forwarded-Proto并用于生成绝对链接（如后端模板渲染）
