nginx全量http→https重定向应使用return 301 https://$host$request_uri;置于仅监听80端口的server块内，避免循环、兼容代理，并关闭rewrite_log以防日志干扰。
这条 rewrite 规则本身就能实现全量 HTTP 到 HTTPS 的重定向，但“优雅”关键在于它是否安全、可维护、不引发循环，且兼容常见部署场景（如反向代理后端、多级负载均衡）。直接套用 rewrite ^(.*)$ https://$host$1 permanent; 在多数 Nginx 配置中是可行的，但需结合上下文谨慎使用。
确保只对 HTTP 请求生效
该规则若放在 http 或 server 块顶层，会无差别触发——包括本就走 HTTPS 的请求，导致重定向循环。必须限定作用域：
- 最稳妥方式：放在仅监听 80 端口的 server 块内（即纯 HTTP 入口）
- 避免写在同时监听 80 和 443 的 server 块里
- 不依赖
$scheme判断，因 rewrite 执行时 scheme 可能已被上游代理覆盖
正确处理 Host 头与端口问题
$host 是客户端请求头中的 Host 字段，通常不含端口；但若用户显式访问 http://example.com:80，重定向后应去掉 :80。Nginx 默认行为已处理这点——$host 自动剥离标准端口（80/443），无需额外干预。
若后端有反向代理（如 ELB、CDN、Traefik），需确认它是否透传真实 Host。否则 $host 可能变成代理 IP 或内部域名，导致跳转错误。
推荐替代写法：return 更清晰、更高效
相比 rewrite，return 语句语义明确、性能略优，且不易误配：
return 301 https://$host$request_uri;-
$request_uri包含完整路径+查询参数，比$1更可靠（尤其当 location 有嵌套或正则匹配时） - 避免
permanent关键字，直接写状态码 301，意图更直观
务必关闭不必要的 rewrite 日志干扰
该规则命中频繁，若开启 rewrite log（调试级别），会大量刷日志。生产环境建议：
- 确认
error_log /path/to/error.log warn;或更高级别 - 避免
rewrite_log on;（默认 off，除非显式开启） - 重定向本身不记录 access log，但可通过
log_format添加$status字段观察 301 比例
