tls握手失败是https连接中断的常见原因，表现为nginx error_log中出现ssl_do_handshake() failed等错误但无http状态码，需通过debug日志、协议/密钥配置检查及客户端模拟验证定位。
当用户访问 HTTPS 服务时出现连接中断、白屏或“Secure Connection Failed”等错误，而服务端 Nginx 日志中又没有常规的 4xx/5xx 状态码，很可能是 TLS 握手阶段就失败了——这类问题不会生成 HTTP 请求记录，Nginx 默认 access_log 里根本看不到，必须依赖 error_log 和专门开启的 SSL debug 日志 才能定位。
确认是否为 TLS 握手失败
Nginx 的 error_log 是第一线索。TLS 握手失败通常表现为：
- SSL_do_handshake() failed（通用失败）
- no protocols available（协商无共同支持协议）
- ssl handshake failed 或 SSL_read failed
- 伴随客户端 IP 和时间戳，但 无 request line、无 status、无 upstream
若 error_log 中频繁出现上述日志，且集中在特定用户群（如老旧安卓设备、IE11、Windows Server 2008 等），基本可锁定为客户端 TLS 版本不兼容。
开启 SSL 详细日志辅助判断
默认 error_log 级别（warn/error）不足以显示协商细节。需临时提升日志级别并启用 SSL 模块调试：
- 在
http或server块中添加：error_log /var/log/nginx/ssl-debug.log debug; - 确保编译时已启用
--with-debug（主流发行版包通常未开启，需自行编译或换用 debug 包） - 重启 Nginx 后复现请求，查看 debug 日志中类似：
SSL: client TLS version: TLSv1.0或SSL: no ciphers enabled for TLSv1.1
注意：debug 日志量极大，仅用于短时排查，定位后务必关掉。
检查 Nginx 的 TLS 协议与 Cipher 配置
握手失败常因服务端禁用了客户端唯一支持的协议版本。检查 ssl_protocols 和 ssl_ciphers：
- 若配置为
ssl_protocols TLSv1.2 TLSv1.3;，则明确拒绝 TLSv1.0/TLSv1.1 客户端 - 某些 cipher 套件（如仅含
CHACHA20或TLS_AES）只在 TLSv1.3 生效，老客户端无法协商 - 推荐兼容性配置（兼顾安全与覆盖）：
ssl_protocols TLSv1.2 TLSv1.3;ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384;
使用 SSL Labs Test 可直观验证服务端实际支持的协议和 cipher 列表。
客户端侧验证与辅助手段
单靠服务端日志有时难以还原客户端真实能力。可结合以下方式交叉验证：
- 用
openssl s_client -connect example.com:443 -tls1_1模拟 TLSv1.1 握手，观察是否报handshake failure - 浏览器访问时按 F12 → Security 标签页，查看“Connection”中显示的协议版本（Chrome/Firefox 支持）
- 对移动 App 或嵌入式设备，抓包分析 ClientHello 中的
legacy_version字段（Wireshark 过滤ssl.handshake.type == 1）
若确认是客户端 TLS 版本过低，且业务需兼容，应评估是否放宽协议限制；否则建议推动客户端升级，而非长期维持不安全协议。
