ssl_do_handshake() failed 表示服务端tls/ssl握手中断，须结合错误码（如141cf06c、14094410）定位具体环节：协议版本不匹配、密钥交换失败、密码套件无交集、证书问题或配置不当。
日志中出现 SSL_do_handshake() failed 表示 TLS/SSL 握手在服务端（如 Nginx、OpenSSL 应用）主动调用该函数时中断，背后具体原因需结合紧随其后的错误码（如 error:141CF06C）判断。不同错误码指向协议层、密钥交换、证书或配置等不同环节的问题，不能一概而论。
常见子错误码及核心含义
error:141CF06C —— tls_parse_ctos_key_share:bad key share
TLS 1.3 握手阶段失败，服务器解析客户端发来的 key_share 扩展时出错。典型原因是：
- 客户端选的椭圆曲线（如 X25519、P-256）不在服务器支持列表中
- 客户端发送的公钥格式非法，或不是该曲线上的有效点
- 中间设备（如旧版负载均衡器）篡改或截断了 key_share 数据
error:14094410 —— ssl3_read_bytes:sslv3 alert handshake failure
TLS 1.2 或更早版本中，服务器收到客户端的 handshake_failure 告警。常见于：
- 双方无共同支持的密码套件（cipher suite）
- 服务器要求客户端证书但未提供，或证书链不完整
- SNI（Server Name Indication）未开启且虚拟主机配置依赖域名区分
error:14209102 —— tls_early_post_process_client_hello:unsupported protocol
服务器在收到 ClientHello 后早期处理阶段即拒绝握手，明确表示协议不兼容。
- 客户端只支持 TLS 1.3，但服务器仅启用 TLS 1.2（或反之）
- Nginx 作为反向代理向上游发起连接时，proxy_ssl_protocols 配置过严，禁用了对方支持的版本
error:1408F10B —— ssl3_get_record:wrong version number
读取 TLS 记录头时发现协议版本字段异常，本质是“数据根本不像 TLS 流”。可能原因：
- 上游服务实际监听的是 HTTP（非 HTTPS），但 Nginx 错误配置为 proxy_pass https://
- 连接被中间防火墙、代理或恶意设备重定向/劫持，返回了纯文本响应
- 客户端复用了一个已关闭连接的 socket，发送了残留或错位的数据
如何快速定位具体错误类型
不要只看报错文字，重点提取三要素：
- 错误码前缀（如 141CF、14094）——对应 OpenSSL 错误表中的模块与原因
- 冒号后函数名（如 tls_parse_ctos_key_share）——指出故障发生在握手哪个子阶段
- 日志上下文中的角色（to upstream 表示 Nginx 是 SSL 客户端；client: x.x.x.x 表示 Nginx 是服务端）
验证建议：
- 对上游服务：用 openssl s_client -connect host:port -tls1_3 -servername example.com 手动测试各协议版本
- 查服务器支持曲线：openssl s_client -connect host:port -tls1_3 -debug 2>&1 | grep "key_share"
- 检查 Nginx 配置中 ssl_protocols、ssl_ciphers、ssl_ecdh_curve 是否合理开放
高频可操作修复方向
多数生产环境问题集中在配置松紧度与协议兼容性上：
- 若日志频繁出现 bad key share，在 Nginx 中显式设置兼容曲线：
ssl_ecdh_curve X25519:P-256;
- 若错误带 to upstream，优先加两行：
proxy_ssl_server_name on;
proxy_ssl_session_reuse off;
- 若提示 unsupported protocol 或 wrong version number，检查 proxy_ssl_protocols TLSv1.2 TLSv1.3; 是否覆盖上游能力
- 禁用 TLS 1.3 临时排查（仅调试）：ssl_protocols TLSv1.2;，确认是否回归稳定
