不能用 Nginx 集群做 HTTP/1.1 与 HTTP/2 的协议版本级负载均衡，因 HTTP/2 由客户端与 Nginx 前端通过 TLS ALPN 协商决定且仅限 HTTPS，后端始终用 HTTP/1.1；集群层无协议感知能力，分流只能基于 User-Agent、域名或路径等间接特征。
不能用 Nginx 集群对 HTTP/1.1 和 HTTP/2 做“协议版本级”的负载均衡。HTTP/2 不是独立服务，它由客户端与 Nginx 之间协商决定，且只在 HTTPS 场景下生效；后端上游（如应用服务器）通常不处理 HTTP/2，Nginx 与它们通信仍用 HTTP/1.1。所谓“按协议分流”，实际是按客户端连接特征做前端路由，而非集群层的协议感知调度。
HTTP/2 的启用完全取决于前端监听配置
Nginx 是否使用 HTTP/2，只看 listen 指令是否同时包含 ssl 和 http2：
-
listen 443 ssl http2;→ 支持 HTTP/2（同时兼容 HTTP/1.1，由 TLS ALPN 协商决定） -
listen 443 ssl;→ 只支持 HTTP/1.1 -
listen 80 http2;→ 无效（明文 HTTP/2 即 h2c 不被主流浏览器支持，Nginx 也仅限特定场景启用）
这意味着：同一台 Nginx 实例可同时服务 HTTP/1.1 和 HTTP/2 客户端，无需多节点集群参与协议选择。
集群中真正可做的“协议相关”分流方式
若需区分处理，只能基于客户端行为间接实现，例如：
-
按 User-Agent 或 TLS 特征识别旧客户端：用
$http_user_agent或$ssl_protocol判断是否可能不支持 HTTP/2，再用if+proxy_pass指向不同 upstream -
按域名或路径分离流量：例如
h2.example.com启用 http2，legacy.example.com禁用，各自指向不同后端组 -
强制降级出口协议：即使客户端支持 HTTP/2，也可在 proxy_pass 前设
proxy_http_version 1.1;，确保发往后端始终为 1.1
后端不需要、也不建议运行 HTTP/2
绝大多数 Web 应用（如 Node.js、Python Flask、Java Spring Boot）默认不暴露 HTTP/2 接口。Nginx 作为反向代理，与 upstream 保持 HTTP/1.1 + keepalive 更稳定高效：
- 配置示例：
upstream backend { server app1:8080; keepalive 32; } - 转发时显式声明：
proxy_http_version 1.1;和proxy_set_header Connection ""; - 强行让 upstream 支持 HTTP/2 会增加复杂度，且无实际收益——多路复用在 Nginx 与客户端之间已生效，后端瓶颈通常不在协议层
安全与兼容性才是关键取舍点
是否启用 HTTP/2，本质是 TLS 配置问题：
- 必须用 TLS 1.2+，推荐启用 TLS 1.3
- 禁用 TLS 1.0/1.1 可提升安全，但会切断 Windows XP、Android 4.4 等老旧环境的 HTTP/2 支持
- 证书必须有效、域名匹配，否则浏览器直接拒绝协商 HTTP/2
这些都发生在单台 Nginx 的 SSL 握手阶段，和集群拓扑无关。
