nginx从1.9.5起支持http/2，但仅限客户端到nginx的https连接；后端默认仍用http/1.1，需显式配置proxy_http_version 2.0及alpn h2才可启用全链路http/2。
Nginx 从 1.9.5 版本起原生支持 HTTP/2，但仅限于 HTTPS 场景下的 server 端监听；它不支持纯 HTTP/2（h2c）明文升级，也不在 upstream 代理链路中主动发起 HTTP/2 请求——后端通信默认仍为 HTTP/1.1。这意味着：HTTP/2 的收益主要体现在客户端到 Nginx 这一跳，而非 Nginx 到后端服务器之间。
HTTP/2 在负载均衡中的实际生效范围
HTTP/2 的关键特性（多路复用、头部压缩、服务端推送）只在 TLS 加密连接上启用，且仅作用于 Nginx 作为终端服务器（即处理客户端请求）时。当 Nginx 充当负载均衡器时：
- 前端（Client → Nginx）可启用 HTTP/2：需配置
listen 443 ssl http2，配合有效证书 - 后端（Nginx → upstream）默认仍是 HTTP/1.1：即使后端也支持 HTTP/2，Nginx 不会自动协商升级
- 若需后端走 HTTP/2，必须显式设置
proxy_http_version 2.0，且后端必须监听 HTTPS 并支持 ALPN h2 协议
生产环境推荐配置要点
兼顾兼容性、安全与性能，避免过度依赖 HTTP/2 特性（如服务端推送在负载均衡场景下易引发缓存混乱或资源竞争）：
- 监听配置中明确启用
http2，并关闭不安全的旧协议：listen 443 ssl http2;ssl_protocols TLSv1.2 TLSv1.3; - 保持 upstream 连接复用，减少 TLS 握手开销：
upstream backend {<br> server app1.example.com:443;<br> server app2.example.com:443;<br> keepalive 32;<br>} - 代理到后端时，如确认后端支持且已部署 HTTPS，可启用 HTTP/2 上游通信：
proxy_http_version 2.0;<br>proxy_set_header Connection '';<br>proxy_ssl_alpn h2;
- 禁用服务端推送（
http2_push off;）：它在负载均衡+动态后端架构中难以精准控制，易造成冗余传输或状态不一致
常见误区与规避建议
很多团队误以为开启 http2 就能全局提速，实际瓶颈常在别处：
-
混淆“是否支持”和“是否生效”：浏览器地址栏显示 h2，只代表 Client↔Nginx 是 HTTP/2；用
curl -I --http2 https://your.site验证，再用nginx -T | grep http2确认配置已加载 -
忽略 keepalive 复用价值：HTTP/2 的多路复用依赖长连接；务必配
keepalive_timeout 75;与 upstream 的keepalive，否则每次请求仍新建 TCP+TLS -
盲目开启服务端推送：Nginx 推送依赖静态
http2_push指令或 Link header，无法感知后端业务逻辑变化；生产环境建议关闭，交由应用层按需控制
HTTP/2 对负载均衡的价值是真实的，但核心在于稳定复用加密连接、降低首字节延迟；不必强求全链路 h2，更应关注证书有效性、TLS 参数调优和 upstream 连接池管理。
