开启HTTP/2需满足Nginx≥1.9.5且启用http_v2模块、OpenSSL≥1.0.2支持ALPN、有效TLS证书，并在listen 443 ssl http2中严格配置，反向代理保持HTTP/1.1+keepalive，再调优header大小、并发流数等参数。
开启 http2 指令本身不等于获得性能提升，它只是启动了协议协商的开关。真正的红利来自全链路 HTTPS 下的头部压缩、多路复用和连接复用，但前提是配置严谨、上游协同、参数适配——否则可能白开，甚至引发降级或连接异常。
必须满足的硬性前提
HTTP/2 在 Nginx 中仅支持 TLS 封装模式（即 h2），不支持明文 h2c（主流浏览器完全忽略）。以下三项缺一不可：
- Nginx 版本 ≥ 1.9.5，且编译时启用了
http_v2模块（可通过nginx -V | grep http_v2验证） - OpenSSL 版本 ≥ 1.0.2（推荐 1.1.1 或 3.x），并启用 TLS 1.2+（
ssl_protocols TLSv1.2 TLSv1.3） - 有效、可信、域名匹配的 SSL 证书（Let’s Encrypt 等签发；自签名证书在 Chrome/Firefox 中将强制回退至 HTTP/1.1）
server 块的关键配置要点
仅在 listen 后加 http2 远不够，需同步加固 TLS 层：
-
listen 443 ssl http2;—— 顺序无关，但必须同时含ssl和http2 - 禁用弱协议与套件：
ssl_protocols TLSv1.2 TLSv1.3;，避免TLSv1.0和SHA1相关套件 - 启用 OCSP Stapling 加速证书验证：
ssl_stapling on; ssl_stapling_verify on;（需配置ssl_trusted_certificate） - 设置会话缓存：
ssl_session_cache shared:SSL:10m; ssl_session_timeout 4h;，显著减少重复握手开销
反向代理层的务实策略
Nginx 到上游服务，强烈建议保持 HTTP/1.1 + keepalive，而非盲目升级到 HTTP/2：
- 内网延迟低，HTTP/1.1 的长连接已足够高效；HTTP/2 多路复用在低延迟场景无明显收益
- 多数后端（Spring Boot、Gunicorn、uWSGI、Tomcat）对代理式 HTTP/2 支持不成熟，易出现流控制失败、RST_STREAM 或连接挂起
- 正确写法示例：
upstream backend {<br> server 10.0.0.1:8443;<br> keepalive 32;<br> }<br> location / {<br> proxy_pass https://backend;<br> proxy_http_version 1.1;<br> proxy_set_header Connection '';<br> }
影响实际并发体验的调优项
HTTP/2 的优势需底层资源配合才能释放：
-
worker_connections 10240;—— 结合worker_processes auto与系统ulimit -n调整，避免连接数瓶颈 - 根据业务 Header 规模调整：
http2_max_header_size 32k;（如含 JWT、OpenTelemetry 追踪头） - 高并发短请求场景可提高复用率：
http2_max_requests 3000;（默认 1000，防过早断连） - 客户端连接稳定性差时延长等待：
http2_recv_timeout 60s;
验证是否生效，优先使用浏览器 Network 面板查看 Protocol 列是否显示 h2；命令行可用：curl -I --http2 https://your-domain.com，返回头中出现 HTTP/2 200 即表示成功。
