不建议在 location 块内做 http 到 https 的强制跳转，因为 location 仅匹配 uri 路径，属请求处理后期逻辑，而协议跳转应在连接初期决策；写在 location / 中语义不清、无法覆盖 acme 验证等特殊路径，且易与 rewrite 或 proxy_pass 冲突。
不建议在 location 块内做 HTTP 到 HTTPS 的强制跳转。
为什么 location 不适合做全局跳转
location 是用于匹配 URI 路径的，它只在 server 已经确定处理该请求的前提下生效。而 HTTP → HTTPS 跳转是协议层的引导行为，应在连接建立初期就决策，不是路径匹配后才触发的逻辑。
- 若把
return 301写在location /里，虽然能跳转，但属于“兜底执行”，语义不清、可读性差 - 无法覆盖所有情况：比如用户访问
http://example.com/.well-known/acme-challenge/xxx（Let’s Encrypt 验证路径），若被 location 拦截跳转，ACME 协议会失败 - 容易和 rewrite、proxy_pass 等指令冲突，增加调试难度
正确做法：用独立的 server 块监听 80 端口
这是 Nginx 官方推荐、生产环境通用的标准方式：
- 新增一个仅监听 80 的
server块，里面只写跳转，不放任何业务配置 - 使用
return 301 https://$host$request_uri;—— 自动保留域名、路径、全部查询参数 -
$host比$server_name更可靠，能正确响应 Host 头里的实际值（如泛解析或多域名场景）
HTTPS server 必须单独且可用
跳转只是“指路”，真正承载内容的是 443 端口的服务：
- 必须有另一个
server { listen 443 ssl; ... }块，且证书路径、TLS 协议、加密套件均配置正确 - 不要在 443 块里漏掉
ssl_certificate和ssl_certificate_key - 若后端是反向代理（如 Node.js、Python 应用），需加
proxy_set_header X-Forwarded-Proto $scheme;，避免重定向循环
代理环境下要额外注意 497 错误码
当 Nginx 前有 CDN 或负载均衡器（如 ALB、Cloudflare）时，用户走 HTTPS，但到 Nginx 是 HTTP，此时 80 端口跳转不生效：
- 在 443 的
server块内添加：error_page 497 =301 https://$host$request_uri; - 确保代理透传
X-Forwarded-Proto: https头 - 若代理头含下划线（如
X-Forwarded-For），需在http块开头启用：underscores_in_headers on;
