Nginx SSL环境下与后端握手超时，核心是确认“与谁握手失败”：若日志出现“while SSL handshaking to upstream”，说明proxy_pass协议不匹配（如后端为HTTP却配https://），或缺失SNI（需proxy_ssl_server_name on及proxy_ssl_name）、SSL会话复用异常（可临时关闭proxy_ssl_session_reuse）。
解决 Nginx SSL 环境下与后端服务的握手超时，核心不是调大超时值，而是先确认“Nginx 正在和谁握手失败”——它作为客户端连接后端 HTTPS 服务时卡住，问题出在 proxy_pass https:// 这一环节。方向错了，所有配置调整都无效。
第一步：从日志精准定位是“连后端失败”
打开 /var/log/nginx/error.log，重点找这行错误前后的上下文：
-
出现
while SSL handshaking to upstream→ 明确表示 Nginx 主动连接后端 HTTPS 服务失败，问题在代理配置层 - 别被
SSL_do_handshake() failed带偏，它只是现象；真正关键的是后面有没有to upstream四个字 - 线上绝大多数此类超时都属于这一类，而非证书或 TLS 版本问题
第二步：检查 proxy_pass 协议是否真实匹配
这是最常见、最容易被忽略的错误：Nginx 配了 https://，但后端根本没开 HTTPS。
- 如果后端监听的是 HTTP（比如 Spring Boot 默认 8080、Node.js 的 http.createServer），
proxy_pass必须写成http://127.0.0.1:8080；写成https://会强制发起 TLS 握手，而对方只认明文 HTTP，直接断连，日志报wrong version number - 验证方法：在 Nginx 服务器上执行
curl -v http://127.0.0.1:8080/health和curl -v https://127.0.0.1:8080/health，看哪个能通 - 若后端确实是 HTTPS（如自签证书的 API），优先用域名访问（
curl -vk https://api.example.com），避免直连 IP 导致 SNI 缺失和证书校验失败
第三步：启用 SNI 并显式指定目标主机名
当后端是多域名 HTTPS 服务（如 K8s Ingress、云厂商 API、Nginx 自身反代多个站点），必须让 Nginx 在 TLS 握手时带上正确的主机名，否则后端无法选择对应证书，直接拒绝握手。
- 在对应
location或upstream的 proxy 段中添加：proxy_ssl_server_name on; - 如果
upstream是 IP 地址或泛域名，还需指定具体目标主机名：proxy_ssl_name "api.example.com";（双引号包裹，大小写敏感） - 同时设置 Host 头保持一致：
proxy_set_header Host "api.example.com"; - 不加
proxy_ssl_server_name on，Nginx 默认不发送 SNI 扩展，日志常报handshake failure
第四步：临时关闭 SSL 会话复用排查状态错乱
默认开启的 proxy_ssl_session_reuse on 可能在后端重启、证书轮换或负载节点不一致时引发兼容性问题，导致密钥协商失败，典型表现是“首次成功、后续全超时”或报 ccs received early。
- 先设为
proxy_ssl_session_reuse off;观察是否还超时，可快速验证是否为该原因 - 关闭后每次新建连接都走完整握手，性能略降，但稳定性优先
- 配合限定协议范围更稳妥：
proxy_ssl_protocols TLSv1.2 TLSv1.3;（避免已淘汰的 TLSv1.0/TLSv1.1）
