SSL握手失败需先据日志区分方向：含“to upstream”则查proxy_pass协议匹配、SNI启用及会话复用；含“client: xxx”则查证书链完整性、TLS版本兼容性及域名匹配，并结合OpenSSL错误码精准定性。
SSL 握手失败不是单一问题，而是协议协商中断的“结果”。排查关键不在猜原因，而在快速定位失败发生在哪一端、哪个环节。下面按实际运维中最高效的顺序展开，每一步都直指可验证的动作。
第一步：看日志，先分清是“谁连谁”失败
打开 Nginx 的 /var/log/nginx/error.log，不读整段，只盯两行关键词：
- 出现 while SSL handshaking to upstream → Nginx 主动连后端（如 API、微服务）失败，问题在 proxy_pass 配置或后端 TLS 实现
- 出现 while SSL handshaking, client: xxx.xxx.xxx.xxx → 外部用户（浏览器、APP）连 Nginx 失败，问题在 server 块的证书、协议或密码套件
90% 的误判源于混淆这两类场景。别跳过这步——方向错了，所有调参都是白忙。
第二步：确认是客户端连 Nginx 失败，查三样硬指标
如果日志明确指向 client，立刻验证以下三项：
-
证书链是否完整：用
openssl s_client -connect yourdomain.com:443 -servername yourdomain.com -showcerts查看输出中是否有多个-----BEGIN CERTIFICATE-----块。缺中间 CA 就会报unable to get local issuer certificate -
TLS 版本是否兜底：Nginx 配置中必须含
ssl_protocols TLSv1.2 TLSv1.3;。禁用 TLS 1.2 会直接导致现代浏览器握手断开 -
域名是否匹配：证书里的 Subject Alternative Name（SAN）必须包含用户实际访问的域名，
www.a.com和a.com是两个独立主体，不可互换
第三步：确认是 Nginx 连后端失败，重点查三配置
常见于 proxy_pass 到 HTTPS 接口时，错误日志带 to upstream：
-
协议写反了：
proxy_pass https://backend但后端只监听 HTTP 端口。用curl -v http://backend-ip:port测试通不通，比改配置更快 -
SNI 没开：后端是多域名托管（如 K8s Ingress、云厂商 API），必须加
proxy_ssl_server_name on;；若用 IP 或泛域名，还得补proxy_ssl_name "api.example.com"; -
会话复用冲突：默认开启的
proxy_ssl_session_reuse on;在后端证书轮换或节点不一致时易触发ccs received early。临时关掉可快速验证：proxy_ssl_session_reuse off;
第四步：用 OpenSSL 错误码定性，比文字描述更准
日志里紧挨着的十六进制错误码才是真实线索：
-
error:14094410→ 缺 SNI 或双方无共同密码套件 -
error:1408F10B→ 协议错配，比如 Nginx 用 HTTPS 去连纯 HTTP 后端 -
error:141CF06C→ TLS 1.3 密钥交换失败，后端 OpenSSL/JDK 版本太老（如 JDK 8u221 以下） -
error:14094085→ccs received early，基本锁定会话复用或后端 TLS 实现兼容性问题
