nginx启用http/2时加密套件冲突的根本原因是tls握手阶段服务端与客户端无法就密钥交换、签名算法或协议版本达成一致，http/2强制要求全aead套件（禁用rc4、3des、md5、sha-1及非pfs套件），配置中若混入被禁套件将导致静默握手失败。
在 Nginx 中启用 HTTP/2 时出现加密套件冲突报错（如 SSL_do_handshake() failed、sslv3 alert handshake failure 或日志中提示 no suitable signature algorithm），根本原因不是“套件太多”，而是服务端与客户端（或上游）在 TLS 握手阶段无法就密钥交换算法、签名机制或协议版本达成一致。这类错误常被误判为证书问题，实则源于 SSL/TLS 配置与 HTTP/2 的强约束不匹配。
确认 HTTP/2 对加密套件的硬性要求
HTTP/2 协议规范（RFC 7540）明确禁止使用以下类型套件：
- 含 RC4、3DES、MD5、SHA-1 哈希的套件（如
ECDHE-RSA-AES128-SHA） - 非 AEAD（Authenticated Encryption with Associated Data）模式的套件（HTTP/2 要求所有加密必须带完整性校验）
- 不支持前向保密（PFS）的静态 RSA 密钥交换
这意味着：哪怕 OpenSSL 和 Nginx 版本达标，只要 ssl_ciphers 包含了被 HTTP/2 禁用的旧套件，Nginx 在协商 HTTP/2 时就会静默拒绝连接，返回握手失败。
配置安全且兼容的加密套件组合
推荐直接采用现代、精简、全 AEAD 的写法，兼顾 TLS 1.2/1.3 和主流客户端支持：
-
强制启用 TLS 1.2 和 1.3：
ssl_protocols TLSv1.2 TLSv1.3;（禁用 TLS 1.0/1.1） -
只保留 ECC 和 RSA 双路径的 GCM 套件：
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384; -
禁用不安全选项：确保未设置
ssl_prefer_server_ciphers off;（默认即 off，但显式设为 on 更可控）；避免ssl_ecdh_curve强制非标准曲线（如 brainpool）
排查上游或后端代理引发的套件不匹配
若 Nginx 作为反向代理访问 HTTPS 上游（proxy_pass https://...），错误可能发生在 到上游 的握手环节（日志中 upstream 字段明显）：
- 检查上游服务器是否支持 TLS 1.2+ 及上述 AEAD 套件；老旧 Java 服务（如 JDK 7u80 以下）默认不支持 GCM
- Nginx 默认不继承 client 的 ALPN，需显式配置上游 TLS 行为：
proxy_ssl_protocols TLSv1.2 TLSv1.3;和proxy_ssl_ciphers（同 server 级配置） - 若上游证书是 RSA 但 Nginx 配置了 ECDSA 优先套件，而上游未提供对应 ECDSA 证书，也会触发
no suitable signature algorithm
验证与快速定位方法
不要只看浏览器表现，用命令行精准验证：
- 测服务端支持：
openssl s_client -connect yoursite.com:443 -alpn h2，观察是否成功协商 ALPN 为h2，并检查Server certificate后的签名算法（应为ecdsa-with-SHA256或rsa_pkcs1_sha256） - 测上游握手：
curl -v --http2 https://your-upstream-domain，或用openssl s_client -connect upstream:443 -alpn h2 - 查看 Nginx error log 中具体报错行，重点找
SSL routines后的子错误码（如handshake failure、unknown cipher returned）
