Nginx启用HTTP/2需全链路HTTPS支持，listen须加http2参数并配置TLS 1.2+、安全套件及有效证书；反向代理上游建议保持HTTP/1.1+keepalive；关键调优包括worker_connections、upstream keepalive等。
要让Nginx反向代理真正支持HTTP/2并提升并发性能，核心不是简单开启h2，而是确保整个链路（客户端→Nginx→上游服务）均兼容且配置合理。否则可能降级为HTTP/1.1，甚至引发连接复用失效、头部压缩异常等问题。
启用HTTP/2必须基于HTTPS
HTTP/2在主流浏览器中仅支持通过TLS启用（即h2，而非h2c明文模式）。Nginx 1.9.5+要求listen指令显式添加http2参数，且SSL配置需满足最低安全要求：
- 使用TLS 1.2或更高版本（推荐TLS 1.3）
- 禁用不安全的加密套件（如RC4、SHA1、TLS 1.0/1.1）
- 证书需有效、域名匹配，建议使用Let’s Encrypt等可信CA签发
示例server块配置：
server {
listen 443 ssl http2;
server_name example.com;
ssl_certificate /path/to/fullchain.pem;
ssl_certificate_key /path/to/privkey.pem;
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:...;
# 其他SSL优化可选：ssl_buffer_size, ssl_session_cache等
}反向代理到上游服务时慎用HTTP/2
Nginx作为反向代理，默认向上游发起的是HTTP/1.1请求。虽然Nginx 1.13.10+支持proxy_http_version 2.0，但实际生产中不建议对后端启用h2，原因包括：
- 多数应用服务器（如Tomcat、Gunicorn、Spring Boot内嵌容器）对HTTP/2反向代理支持不完善，易出现流控制错误或连接挂起
- 内部网络延迟低，HTTP/1.1 + keepalive已足够高效；HTTP/2的多路复用优势在内网无明显收益
- 增加调试复杂度：需同时排查Nginx、上游服务、TLS中间件（如Envoy）的h2帧交互问题
保持上游使用HTTP/1.1 + 连接池更稳定：
location / {
proxy_pass https://backend;
proxy_http_version 1.1;
proxy_set_header Connection '';
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
}关键性能调优项（非HTTP/2独有但影响显著）
HTTP/2本身能提升并发体验，但若Nginx基础参数不合理，反而成为瓶颈：
- worker_connections：每个worker进程允许的最大并发连接数，需结合worker_processes auto与系统ulimit -n调整（例如设为10240）
-
keepalive：对上游启用长连接，减少握手开销：
upstream backend {
server 10.0.0.1:8443;
keepalive 32;
}
location / {
proxy_http_version 1.1;
proxy_set_header Connection '';
} - sendfile & tcp_nopush：加速静态资源传输，避免小包堆积
- client_body_timeout / client_header_timeout：防止慢速攻击耗尽连接，建议设为10~30秒
验证是否真正运行在HTTP/2
不要只看响应头中的Alt-Svc或浏览器开发者工具“Protocol”字段，需综合确认：
- 用curl检查：
curl -I --http2 https://example.com，返回状态行应为HTTP/2 200 - Chrome DevTools → Network → 右键表头 → 勾选“Protocol”，查看请求是否显示h2
- 抓包验证（Wireshark）：过滤http2，观察SETTINGS、HEADERS等帧是否正常交换
- 注意：若Nginx与上游之间用了h2但客户端未走HTTPS，或证书不被信任，仍会回退到HTTP/1.1
