HTTPS重定向需基于X-Forwarded-Proto头判断客户端真实协议，仅在80端口server块中配置301跳转，Kubernetes Ingress应通过annotation控制，重定向URL用$request_uri保留参数。
在微服务网关场景下，Nginx 作为边缘反向代理或 Kubernetes Ingress Controller 的底层实现时，HTTPS 重定向不能简单照搬单体应用的配置——它必须与网关流量模型、TLS 终止位置、客户端真实协议感知协同工作。核心在于：重定向逻辑要基于“客户端实际发起的协议”，而非 Nginx 自身接收请求的协议（尤其当上游有 Azure App Gateway、AWS ALB 或云厂商 WAF 时）。
识别真实客户端协议
云环境常见架构中，客户端 → 负载均衡器（HTTPS 终止）→ Nginx（HTTP 内网通信），此时 $scheme 永远是 http，直接判断会失效。正确做法是依赖负载均衡器注入的 HTTP 头：
- 检查
X-Forwarded-Proto请求头：大多数云网关（如 AWS ALB、Azure App Gateway、Traefik）会自动添加该头，值为https或http - 在 server 块中启用
set_real_ip_from和real_ip_header，确保$remote_addr可信（避免伪造） - 用
if ($http_x_forwarded_proto != "https") { return 301 https://$host$request_uri; }替代if ($scheme = http)
避免重定向循环
当 Nginx 本身不终止 TLS，而由前置网关处理 HTTPS 时，若仍监听 443 并配置 SSL，或错误地对内网请求做重定向，极易触发 301 循环。关键防范点：
- 仅在监听 80 的 server 块中配置重定向逻辑；443 server 块只负责业务转发，不加任何重定向指令
- 确认前置网关已开启“强制 HTTPS”功能（如 ALB 的 Redirect HTTP to HTTPS），此时 Nginx 层可完全移除重定向配置
- 若需 Nginx 控制，务必限制重定向只作用于外部入口域名，排除内部服务调用（例如通过
server_name明确指定公网域名，而非localhost或内网 IP）
适配 Kubernetes Ingress 场景
当 Nginx 以 Ingress Controller（如 nginx-ingress）运行时，重定向应由 Ingress 资源声明，而非手动改 ConfigMap：
- 在 Ingress YAML 中添加 annotation：
nginx.ingress.kubernetes.io/ssl-redirect: "true" - 配合
nginx.ingress.kubernetes.io/force-ssl-redirect: "true"实现全量强制跳转 - 证书由 Secret 提供，Ingress Controller 自动注入到 443 server 块；HTTP server 块由控制器统一生成并内置 301 逻辑，无需手写
保留原始路径与参数的细节处理
重定向 URL 构建看似简单，但微服务常依赖完整 query string 或 fragment，需注意：
- 使用
$request_uri（含 path + query）而非$uri（仅 path），避免丢参 - 若后端服务依赖 hash fragment（如 SPA 路由），标准 HTTP 重定向无法传递 fragment，需前端配合 history API 或服务端渲染兜底
- 对特殊字符（如空格、中文）不做额外 encode：Nginx 的
$request_uri已是解码后的原始 URI，直接拼接即可，重复 encode 反而导致乱码
