Nginx实现HTTP到HTTPS的301重定向首选return 301指令，配置listen 80的server块并返回https://$host$request_uri，确保保留原始路径与参数；另需独立配置listen 443 ssl的server块启用SSL证书，最后通过nginx -t验证并reload生效。
直接在 Nginx 的 80 端口 server 块中配置跳转，是最常见也最有效的做法。核心目标是：用户访问 http://example.com 时，301 永久重定向到 https://example.com/原路径，且不引发循环、不丢失参数、不依赖后端逻辑。
方案一：return 301（推荐首选）
语法简洁、执行高效、无正则开销，Nginx 官方明确推荐用于简单重定向场景。
-
配置示例：
return 301 https://$server_name$request_uri; -
优势：不触发 rewrite 引擎，性能最优；
$request_uri自动保留完整路径+查询参数（如?id=123&ref=test）；语义清晰，不易出错 -
注意点：确保
server_name已正确设置；若使用多域名，建议用$host替代$server_name，避免硬编码导致泛域名跳转失败
方案二：rewrite + permanent（兼容旧版本）
历史沿用广泛，适用于 Nginx 1.19 之前或需配合复杂条件判断的场景，但底层仍走 rewrite 流程，略重。
-
配置示例：
rewrite ^(.*)$ https://$host$1 permanent; - 优势：支持更灵活的正则捕获与路径改写（例如统一去除尾部斜杠、重写子目录结构）
-
风险点：
permanent等价于 301，但若正则书写不当（如未加^和$），可能误匹配或截断参数；$1仅捕获路径，不包含 query string，需额外拼接$is_args$args才能保参
方案三：error_page 497（代理环境专用）
不适用于直连场景，专为「上层有 HTTPS 终结代理（如 AWS ALB、CDN、Traefik）」设计，解决 $scheme 始终为 http 的问题。
-
原理：当代理将 HTTPS 请求以 HTTP 协议转发给 Nginx 时，Nginx 收到非 SSL 请求却配置了
ssl on，会返回 497 错误；利用error_page 497捕获并跳转 -
关键配置：
error_page 497 https://$host$request_uri;，同时需确认代理透传了X-Forwarded-Proto: https，并在 Nginx 中启用underscores_in_headers on;（若 Header 含下划线） - 适用边界：仅当 Nginx 不直接面对用户、而是部署在反向代理后端时才有效；直连模式下该配置无效甚至引发异常跳转
三种方式本质都是发 301 响应，区别在于触发机制与适用上下文。生产环境优先选 return；需路径重写逻辑再考虑 rewrite；有可信代理且无法修改其行为时，才启用 error_page 497 方案。
