服务器故障排查如何排查 SSL 握手失败的故障

SSL握手失败需先据日志区分方向：含“to upstream”则查proxy_pass协议匹配、SNI启用及会话复用；含“client: xxx”则查证书链完整性、TLS版本兼容性及域名匹配，并结合OpenSSL错误码精准定性。

SSL 握手失败不是单一问题，而是协议协商中断的“结果”。排查关键不在猜原因，而在快速定位失败发生在哪一端、哪个环节。下面按实际运维中最高效的顺序展开，每一步都直指可验证的动作。

第一步：看日志，先分清是“谁连谁”失败

打开 Nginx 的 /var/log/nginx/error.log，不读整段，只盯两行关键词：

1. 出现 while SSL handshaking to upstream → Nginx 主动连后端（如 API、微服务）失败，问题在 proxy_pass 配置或后端 TLS 实现
2. 出现 while SSL handshaking, client: xxx.xxx.xxx.xxx → 外部用户（浏览器、APP）连 Nginx 失败，问题在 server 块的证书、协议或密码套件

90% 的误判源于混淆这两类场景。别跳过这步——方向错了，所有调参都是白忙。

第二步：确认是客户端连 Nginx 失败，查三样硬指标

如果日志明确指向 client，立刻验证以下三项：

1. 证书链是否完整：用 openssl s_client -connect yourdomain.com:443 -servername yourdomain.com -showcerts 查看输出中是否有多个 -----BEGIN CERTIFICATE----- 块。缺中间 CA 就会报 unable to get local issuer certificate
2. TLS 版本是否兜底：Nginx 配置中必须含 ssl_protocols TLSv1.2 TLSv1.3;。禁用 TLS 1.2 会直接导致现代浏览器握手断开
3. 域名是否匹配：证书里的 Subject Alternative Name（SAN）必须包含用户实际访问的域名，www.a.com 和 a.com 是两个独立主体，不可互换

第三步：确认是 Nginx 连后端失败，重点查三配置

常见于 proxy_pass 到 HTTPS 接口时，错误日志带 to upstream：

1. 协议写反了：proxy_pass https://backend 但后端只监听 HTTP 端口。用 curl -v http://backend-ip:port 测试通不通，比改配置更快
2. SNI 没开：后端是多域名托管（如 K8s Ingress、云厂商 API），必须加 proxy_ssl_server_name on;；若用 IP 或泛域名，还得补 proxy_ssl_name "api.example.com";
3. 会话复用冲突：默认开启的 proxy_ssl_session_reuse on; 在后端证书轮换或节点不一致时易触发 ccs received early。临时关掉可快速验证：proxy_ssl_session_reuse off;

第四步：用 OpenSSL 错误码定性，比文字描述更准

日志里紧挨着的十六进制错误码才是真实线索：

1. error:14094410 → 缺 SNI 或双方无共同密码套件
2. error:1408F10B → 协议错配，比如 Nginx 用 HTTPS 去连纯 HTTP 后端
3. error:141CF06C → TLS 1.3 密钥交换失败，后端 OpenSSL/JDK 版本太老（如 JDK 8u221 以下）
4. error:14094085 → ccs received early，基本锁定会话复用或后端 TLS 实现兼容性问题