直接用proxy_pass https://代理HTTPS后端存在四大陷阱：后端证书默认不校验、协议与头信息丢失、重定向Location头未重写、SSL握手参数不兼容现代TLS。
直接用 proxy_pass https:// 代理 HTTPS 后端，看似一步到位，实则暗藏多个关键陷阱。Nginx 默认不验证后端证书、不透传协议头、不处理重定向跳转，稍有疏忽就会导致连接失败、证书告警、跳转错乱或安全降级。
后端证书校验失效：默认跳过 TLS 验证
Nginx 的 proxy_pass https:// 不会主动校验后端服务器的证书有效性——既不检查域名匹配，也不验证证书链和过期时间。这意味着：自签名证书、过期证书、域名不匹配的证书都能“畅通无阻”通过代理，但后端服务一旦异常（如证书吊销、中间 CA 变更），Nginx 完全无法感知，错误会静默传递给客户端或直接中断连接。
解决方法需显式开启验证：
- 添加
proxy_ssl_verify on;启用证书校验 - 指定可信 CA 证书路径：
proxy_ssl_trusted_certificate /etc/nginx/ssl/ca-bundle.crt; - 强制验证主机名：
proxy_ssl_verify_depth 2;和proxy_ssl_name "backend.example.com"; - 若后端使用自签名证书，必须把其根证书加入
proxy_ssl_trusted_certificate，不能依赖系统信任库
协议与头信息丢失：HTTPS 后端 ≠ 自动透传 HTTPS 上下文
即使后端是 HTTPS，Nginx 默认不会把原始请求的协议（$scheme）、真实客户端 IP（$remote_addr）或 Host 头原样转发。后端应用若依赖 X-Forwarded-Proto 判断是否启用 HTTPS 跳转，或依据 Host 做路由分发，就极易出错。
必须手动补全关键头字段：
-
proxy_set_header Host $host;—— 避免后端解析出错的 Host -
proxy_set_header X-Forwarded-Proto $scheme;—— 明确告知后端原始协议是 HTTP 还是 HTTPS -
proxy_set_header X-Real-IP $remote_addr;和proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;—— 恢复真实客户端 IP 链 - 若后端需识别 SNI 域名，还需加
proxy_ssl_server_name on;开启 SNI 透传
重定向响应被篡改：Location 头未自动重写
这是最隐蔽也最常被忽略的问题。当后端返回 301/302 重定向时，其 Location 响应头通常包含完整的 HTTPS 地址，例如 https://internal-app:8443/dashboard。Nginx 不会自动将该地址重写为面向公网的域名，而是原样返回给浏览器——结果就是用户被跳转到不可达的内网地址或错误端口，最终 404 或连接超时。
修复方式有两种：
- 启用
proxy_redirect自动替换：proxy_redirect https://internal-app:8443/ https://public.example.com/; - 更健壮的做法是关闭自动重定向，由后端统一构造公网 URL；或在 Nginx 中用
sub_filter动态替换响应体中的链接（需启用sub_filter_types text/html;） - 务必测试所有可能触发重定向的路径（登录、登出、表单提交、OAuth 回调等）
SSL 握手与性能隐患：默认参数不兼容现代 TLS
Nginx 作为 TLS 客户端连接后端时，使用的 TLS 版本、加密套件、会话复用策略均独立于前端配置。若后端只支持 TLS 1.3 或特定 ECDHE 曲线，而 Nginx 仍用老旧默认值，握手就会失败。
建议显式收紧后端 TLS 行为：
proxy_ssl_protocols TLSv1.2 TLSv1.3;proxy_ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256;-
proxy_ssl_session_reuse on;提升连接复用率 -
proxy_ssl_verify_depth 3;确保能验证含多级中间证书的链
