HTTP/2在Nginx中必须运行于TLS加密通道（HTTPS），依赖OpenSSL≥1.0.2（推荐≥1.1.1）、Nginx≥1.9.5，且需配置listen 443 ssl http2；禁用TLS 1.0/1.1虽提升安全但影响老旧系统兼容性。
HTTP/2 在 Nginx 中必须运行在 TLS 加密通道上（即 HTTPS），且不支持明文 HTTP/2（h2c），因此其兼容性核心取决于 SSL/TLS 协议版本、加密套件以及 Nginx 和 OpenSSL 的组合能力。配置不当会导致客户端协商失败、降级到 HTTP/1.1，甚至连接中断。
HTTP/2 依赖的 TLS 基础条件
Nginx 启用 http2 的前提是：SSL 终止已启用、监听地址明确声明 ssl http2，且底层 OpenSSL 版本 ≥ 1.0.2（推荐 ≥ 1.1.1）。Nginx 自身需 ≥ 1.9.5（正式支持 HTTP/2）；若使用较老发行版（如 CentOS 7 默认 OpenSSL 1.0.2k），虽可启用 HTTP/2，但不支持 TLS 1.3。
- 必须使用
listen 443 ssl http2;，仅写ssl不会启用 HTTP/2 - 不支持 ALPN 协商的旧客户端（如 OpenSSL
- 禁用 TLS 1.0/1.1 虽提升安全性，但会切断部分老旧系统（如 Windows XP IE8、旧嵌入式设备）的 HTTP/2 支持
推荐的 TLS 协议与加密套件配置
为兼顾安全与广泛兼容，建议明确启用 TLS 1.2 和 TLS 1.3，禁用不安全旧协议，并选用现代、高效且支持 HTTP/2 的加密套件：
-
ssl_protocols TLSv1.2 TLSv1.3;—— TLS 1.3 无需额外模块，OpenSSL 1.1.1+ 自动支持 -
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384;—— 优先 ECC 密钥交换，全为 AEAD 套件，符合 HTTP/2 强制要求 - 避免含
RC4、3DES、MD5、SHA1的套件，它们被 HTTP/2 规范明确禁止
常见兼容性问题与排查方法
用户访问时未使用 HTTP/2，通常不是配置遗漏，而是协商环节被阻断：
- 用浏览器开发者工具 → Network 标签页，查看响应头中是否有
HTTP/2协议标识；或执行curl -I --http2 https://yoursite.com验证 - 若返回
HTTP/1.1，检查 Nginx 错误日志是否报no suitable signature algorithm（常因私钥格式错误或缺少 ECDSA 证书）、或ALPN negotiation failed（OpenSSL 版本低或未编译 ALPN 支持） - Cloudflare、CDN 或前端负载均衡器若未透传 ALPN 或终止在 TLS 1.2 以下，也会导致后端 Nginx 无法协商 HTTP/2
多证书与 HTTP/2 的协同配置要点
当使用 RSA + ECDSA 双证书提升兼容性（例如 Let’s Encrypt 提供的 ECC 证书用于现代客户端，RSA 用于旧客户端），需注意：
- Nginx ≥ 1.11.0 支持
ssl_certificate和ssl_certificate_key多次声明，实现双证书共存 - 务必为 ECDSA 证书配对 ECDSA 私钥，RSA 证书配对 RSA 私钥；混用将导致 TLS 握手失败，HTTP/2 无法建立
- 双证书本身不改变 HTTP/2 行为，但能扩大支持 ALPN + 现代套件的客户端覆盖范围
