排查nginx故障转移中ssl握手失败，核心是锁定“谁连谁”：含“to upstream”说明nginx连备用后端失败，需查其协议真实性、sni配置及会话复用；含“client: xxx”则表明客户端连nginx自身失败，多因主备ssl配置不一致。
排查Nginx故障转移（failover）过程中SSL握手失败与重试异常，核心是明确“谁在跟谁握手”——故障转移本身不引发SSL错误，但会放大配置缺陷。问题往往藏在重试路径切换后的协议不一致、证书上下文错位或会话状态残留中。
先看error.log锁定握手方向
打开/var/log/nginx/error.log，重点找紧邻SSL_do_handshake() failed的上下文：
- 出现
while SSL handshaking to upstream→ Nginx作为客户端，在尝试连接备用后端（如backup server、健康检查切换后的节点）时失败 - 出现
while SSL handshaking, client: xxx.xxx.xxx.xxx（无upstream字样）→ 客户端在故障转移期间连Nginx自身失败，说明主备切换可能触发了证书/协议配置漂移（如备用server块未启用SSL或证书路径错误）
查备用后端的真实协议与SNI支持
故障转移常把请求切到平时不常用或未充分验证的backup节点，这些节点容易存在协议裸奔或SNI盲区：
- 用
curl -v https://backup-ip:port和curl -v http://backup-ip:port分别测试，确认备用后端是否真监听HTTPS；若仅HTTP通，proxy_pass必须用http://，而非强行https:// - 若备用后端是多域名HTTPS（如K8s Ingress、云API），必须在upstream或location中显式开启：
proxy_ssl_server_name on;，并指定proxy_ssl_name "api.example.com"; - 检查backup节点是否使用自签名或过期证书：用
openssl s_client -connect backup-ip:443 -servername api.example.com -verify_return_error直连验证
关掉会话复用，避免状态污染
故障转移常伴随后端重启、证书轮换或节点异构，而默认开启的proxy_ssl_session_reuse on会复用旧会话ID，导致重试时收到ccs received early（error:14094085）等异常：
- 临时关闭复用：
proxy_ssl_session_reuse off;，观察重试是否恢复正常 - 若关闭后问题消失，说明备用节点TLS实现与主节点不一致（如OpenSSL版本差异、JDK TLS栈兼容性问题），需统一后端TLS环境
- 不建议长期关闭，可配合
proxy_ssl_trusted_certificate和严格证书校验提升安全性
验证重试逻辑与超时配置是否合理
SSL握手失败后Nginx会按proxy_next_upstream策略重试，但若超时设置短于实际握手耗时，会掩盖真实握手问题：
- 检查是否配置了
proxy_next_upstream error timeout http_502;，确保包含http_502（SSL握手失败常返回502） - 确认
proxy_connect_timeout和proxy_ssl_handshake_timeout是否足够（建议≥15s），避免因超时中断握手过程被误判为协议失败 - 对比主备节点的TLS版本支持：用
openssl s_client -connect backup-ip:443 -tls1_2和-tls1_3分别测试，若主节点支持TLSv1.3而backup只支持TLSv1.2，需在upstream中显式限定proxy_ssl_protocols TLSv1.2;
