SSL握手失败——八成卡在协议版本

报错里跳出握手失败，第一反应是去换证书的人，十有八九白折腾一趟。SSL握手失败八成卡在协议版本——两边谈不拢用哪一代协议，加密套件和证书这些根本还没轮到上场。就像两个人约见面，一个只说方言、一个只讲外语，还没聊到正事就已经散了。

SSL握手失败八成卡在协议版本，证书往往是无辜的

证书这玩意儿负责的是证明身份，属于握手中后段的事。可握手第一步是 ClientHello 和 ServerHello，先协商版本、再挑加密套件，前面的门都没进去，后面的戏自然演不了。所以你会看到一堆五花八门的报错：浏览器给 ERR_SSL_VERSION_OR_CIPHER_MISMATCH 或者 ERR_SSL_PROTOCOL_ERROR，curl 里冒出 sslv3 alert handshake failure，openssl 直接甩一句 no protocols available。看到 handshake failure 就急着续证书、重签、装新的，多半是白忙。

协议版本到底是谁在定

这件事两头都有份。TLS 1.0 和 1.1 早就被主流浏览器判了死刑，Chrome、Firefox 这些都不再支持；不少服务端为了省事，默认只留 TLS 1.2 和 1.3。这时候要是有个只会说 TLS 1.0 的客户端撞上来——老系统上的旧浏览器、某些老旧 Java 运行环境、嵌入式设备、很久没升级的采集脚本、甚至某个支付通道的回调——服务端一听版本不认识，当场就把连接掐了。反过来也一样，服务端要是只开 1.3，中间某台老设备、某个旧版本的库不认，照样握不上。所以方向不是只有一个，得看日志说话。

怎么确认是版本惹的祸

先用命令行摸一遍底，比在控制台里瞎点强。openssl s_client -connect 你的域名:443 -servername 你的域名，回车之后看它回给你的 Protocol 和 Cipher 是哪一档；要是直接报错，就手动加上 -tls1_2 或者 -tls1 再试一次。curl -v https://你的域名 也能看到 TLS 握手那几行，协商到哪个版本写得明明白白。浏览器这边打开开发者工具的 Security 面板，当前连接用的版本和套件都能看到。判断逻辑很简单：指定低版本能通、啥都不指定就不通，那基本就锁定了是版本协商这一步出的问题，别再怀疑证书链。

服务端改起来就一两行，但别乱放手

nginx 里就是 ssl_protocols TLSv1.2 TLSv1.3; 这一行的事。有些人为了迁就一个老客户端，把 TLSv1 也打开，这等于给自己埋雷，后面被扫描器点名、被合规检查挑出来，麻烦比省下的那点兼容性大得多。真碰上老设备必须兼容，我一般更愿意在边缘这一层单独放开，源站收紧——反正 CDN、反向代理、负载均衡这些地方通常都有独立的 TLS 策略开关。要注意负载均衡和源站之间是两段握手，只改一头等于没改。还有个坑：开了 HTTP/2 就必须 TLS 1.2 以上，你要是同时留着 TLS 1.0，本身就是个自相矛盾的配置，报错出来一点都不冤。

客户端老旧，锅不一定在你这边

有些握手失败只出现在特定人群身上：公司内网那批没换的旧终端、某个平台的异步回调、某个爬得挺勤的采集器。这时候去看访问日志，很多日志格式里能直接记 $ssl_protocol 这个变量，把版本字段拉出来一统计，是哪一类客户端在拉低水位就一目了然。如果确认对方只会老版本，摆在面前的就两条路——在边缘给它留个降级口子，或者让对方升级。哪个划算自己掂量，没有标准答案，但至少别再把锅甩给证书。

还有几根线容易被看成版本问题

SNI 缺失就挺坑：老客户端不发 SNI，同一个 443 端口上挂了好几个域名时，服务端可能随手返回一张不对的证书，现象看着特别像握手失败，实际跟版本没关系。加密套件不重合也长一个样——版本谈拢了，可双方支持的 cipher 一个都没交集，最后还是 handshake failure。系统时间跑偏同样能让人抓狂，服务器时钟要是飘到证书生效时间之前，握手一样过不去，这种错还特别难往时间上想。再就是双向认证，对方没带客户端证书，报错信息也长得很像。所以说看到握手失败别只认一个原因，把这几条挨个排掉，剩下的才是真凶。

要我说排查顺序就这么走：先拿 openssl 和 curl 确认协商版本，再翻日志看是哪些客户端在失败，然后检查服务端 ssl_protocols 和负载均衡上的 TLS 策略是不是两段不一致，最后才回头怀疑证书、时间、SNI 和加密套件。协议版本这关过了，后面那些加密套件、证书链的问题才有机会露头。真拿不准的配置项，以服务商或官方文档的说明为准，别照着几年前的老教程抄。