关键不是“打开看看”，而是用 OpenSSL 主动探测各 TLS 版本握手是否成功、检查 Nginx 实际支持的密码套件、对照终端环境能力边界（如 Android 4.4 仅支持 TLS 1.0、iOS 9 支持 TLS 1.2）、抓包定位中断位置（ClientHello/ServerHello/RST）。
测试 Nginx HTTPS 配置在不同浏览器下的握手兼容性，关键不是“打开看看”，而是模拟真实客户端的协议和密码套件能力，定位到底是 TLS 版本不支持、套件不匹配，还是中间链路干扰。下面这几种方法最直接有效。
用 OpenSSL 主动探测各 TLS 版本是否可达
在服务器或跳板机上运行以下命令，逐个验证 TLS 协议版本能否完成握手：
-
TLS 1.0：
openssl s_client -connect example.com:443 -tls1 -servername example.com -
TLS 1.1：
openssl s_client -connect example.com:443 -tls1_1 -servername example.com -
TLS 1.2：
openssl s_client -connect example.com:443 -tls1_2 -servername example.com -
TLS 1.3：
openssl s_client -connect example.com:443 -tls1_3 -servername example.com
观察输出：若某条命令卡在连接后立即断开、无 Certificate 段、返回 handshake failure 或 ssl handshake failure，说明该版本被 Nginx 或上游设备（如 WAF、LB）明确禁用。注意：OpenSSL 1.0.2 不支持 TLS 1.3，测试前先确认本地 openssl 版本（openssl version）。
检查 Nginx 实际协商出的加密套件
运行命令查看当前配置下，Nginx 对 TLS 1.2 支持哪些可用套件：
openssl s_client -connect example.com:443 -tls1_2 -cipher 'ALL:eNULL' 2>/dev/null | grep "Cipher is"
如果输出为空或仅显示 Cipher is 0000，说明 Nginx 的 ssl_ciphers 配置过于严格，或与客户端支持的套件无交集。常见问题包括：
– 启用了仅 TLS 1.3 支持的套件（如 TLS_AES_128_GCM_SHA256），却强制要求 TLS 1.2 客户端也使用；
– 错误启用了已废弃套件（如含 RC4、MD5、DES）导致现代 OpenSSL 拒绝协商。
对照真实终端环境的能力边界
不同浏览器/系统底层依赖的 TLS 栈差异很大，不能只看桌面 Chrome。重点关注这些典型组合：
-
Android 4.4 及更早 WebView：仅支持 TLS 1.0，不识别 SNI，需确保 Nginx 未关闭
ssl_protocols TLSv1（但生产环境应避免） -
iOS 9 / Safari 9：支持 TLS 1.2，但不支持
secp521r1椭圆曲线，若 Nginx 强制指定该曲线可能握手失败 -
Java 应用（如老 JDK 6/7）：默认不支持 TLS 1.2，需检查 JVM 启动参数是否启用（
-Dhttps.protocols=TLSv1.2）及 Nginx 是否允许降级 - 企业内网 IE 套壳浏览器：常基于老旧 Trident 内核，只认 SHA-1 签名证书（已淘汰），或无法解析 SAN 字段——此时需确认证书是否含正确 SAN，且未使用 ECDSA 签名
抓包确认握手中断位置
用 Wireshark 或 tcpdump 抓取客户端到 Nginx 的 443 端口流量，重点看：
- 客户端是否发出
ClientHello？ - Nginx 是否回应
ServerHello？ - 之后是否缺失
Certificate或直接出现TCP RST？
若 ServerHello 后立刻 RST，基本可判定是协议/套件不兼容；若连 ServerHello 都没发出来，问题可能出在防火墙拦截、SNI 不匹配、或 Nginx 未监听对应 IP/端口。
