关键信号是日志中出现“no shared cipher”或错误码error:1417A0C1，表明客户端与Nginx（或Nginx与后端）无共同支持的密码套件；需结合client IP方向判断问题端，并用openssl s_client实测两端真实套件交集后，针对性调整ssl_ciphers配置。
排查 Nginx TLS 握手失败是否由加密算法（密码套件）不匹配引起，关键不是比对配置列表，而是验证两端实际协商能力——日志里“no shared cipher”或错误码 error:1417A0C1 就是明确信号。
看日志确认是套件问题
打开 /var/log/nginx/error.log，找含以下特征的行：
- 出现 SSL_do_handshake() failed (SSL: error:1417A0C1:SSL routines:tls_post_process_client_hello:no shared cipher)
- 或文字描述为 "no shared cipher"、"handshake failure" 且上下文不含 SNI 缺失、协议错配等明显线索
- 错误前一行是 while SSL handshaking, client: xxx（服务端接收失败）或 while SSL handshaking to upstream（代理后端失败）
区分问题发生在哪一端
方向决定查什么：
- client: xxx 类错误 → 客户端（浏览器/App/设备）与 Nginx 之间无共同套件。常见于老 Android、IE11、嵌入式系统或定制 WebView
- to upstream 类错误 → Nginx 作为客户端，与后端 HTTPS 服务（如 Java API、云服务）之间套件无交集。多见于后端 OpenSSL 或 JDK 版本老旧（如 JDK 8u221 以下）
用 openssl 实测真实支持的套件
绕过 Nginx 配置，直连目标端口验证协商结果：
- 查 Nginx 服务端支持哪些套件（模拟客户端）：
echo | openssl s_client -connect yourdomain.com:443 -tls1_2 -cipher 'ALL:eNULL' -servername yourdomain.com 2>/dev/null | grep "Cipher is" - 查后端服务支持哪些套件（若为 to upstream）：
echo | openssl s_client -connect backend-ip:port -tls1_2 -cipher 'ALL:eNULL' -servername api.example.com 2>/dev/null | grep "Cipher is" - 若输出为空或报 no ciphers available，说明该 TLS 版本下确实无可用套件
针对性调整 ssl_ciphers 配置
不要盲目抄“安全推荐”，要补交集：
- 对老安卓（4.4–6.x）、旧 IE 等客户端：在 ssl_ciphers 开头加兼容项，例如
ECDHE-RSA-AES128-SHA:ECDHE-RSA-AES256-SHA:AES128-SHA:AES256-SHA - 对 to upstream 场景，若后端只支持 TLSv1.2 且套件老旧，可临时放宽：
proxy_ssl_ciphers ECDHE-RSA-AES128-SHA:ECDHE-RSA-AES256-SHA:DEFAULT; - 务必配合 ssl_prefer_server_ciphers on;，确保服务端主导套件选择
