Nginx 不支持 HTTP/2 到后端的代理，仅客户端到 Nginx 支持 HTTP/2；后端通信默认且只能使用 HTTP/1.1，需配置 proxy_http_version 1.1 并清除 Connection 头以确保兼容。
Nginx 本身不支持将 HTTP/2 帧头（如 HEADERS、DATA、PRIORITY 等）透传或代理给后端服务，也不能作为“HTTP/2 到 HTTP/2”的反向代理链路中的一环去转发原始帧。这是由协议层和 Nginx 架构决定的——它只在客户端到 Nginx 这一跳支持 HTTP/2；而 Nginx 到上游后端默认使用 HTTP/1.1，且无法把接收到的 HTTP/2 帧解包后再以帧形式发给后端。
所以，“配置 Nginx 代理处理后端返回的 HTTP/2 帧头”这个需求，在标准 Nginx 中没有对应实现，也不符合设计逻辑。你需要明确区分两个方向：
- ✅ 客户端 → Nginx：可启用 HTTP/2（必须 HTTPS +
listen 443 ssl http2） - ❌ Nginx → 后端：不支持 HTTP/2 协议通信（即不能用
proxy_http_version 2.0，该指令不存在）
真正可行的配置路径是：
让客户端享受 HTTP/2，Nginx 负责正确解析、分帧、流控，并以 HTTP/1.1 转发给后端——这正是 Nginx 的标准行为，无需额外“处理帧头”，只需确保不干扰协议协商与头部传递。
关键配置要点
-
客户端侧必须走 HTTPS + HTTP/2：监听行写成
listen 443 ssl http2;，并配好 TLSv1.2+、ALPN、可信证书 -
反向代理保持 HTTP/1.1：Nginx 默认用 HTTP/1.1 连接后端，推荐显式声明：
proxy_http_version 1.1;<br>proxy_set_header Connection "";
避免因 Connection: keep-alive 导致 HTTP/1.1 升级失败或连接复用异常 -
不要尝试“透传帧”或修改帧结构：Nginx 不暴露帧级接口，
http2_max_field_size、http2_max_header_size等参数仅用于控制自身对客户端请求帧的接收与解析边界，不影响后端通信 - 若后端也需 HTTP/2 支持，请绕过 Nginx 或换架构：比如用 Envoy、Caddy 或自研网关；或者让后端直接面向公网（不推荐），或通过 gRPC over HTTP/2 等专用通道通信
常见误解澄清
-
没有
proxy_http_version 2.0：Nginx 官方至今（2026年）未实现 upstream HTTP/2，相关 PR 多次被拒绝，因其违背“Nginx 是边缘代理而非协议桥接器”的定位 - 不存在“后端返回的 HTTP/2 帧头”需要 Nginx “处理”：后端返回的是 HTTP/1.1 响应（状态行+头部+body），Nginx 将其封装为 HTTP/2 的 HEADERS+DATA 帧发给客户端——这个转换是自动完成的，不可干预，也不需配置
-
server push 不等于帧头代理：
http2_push是 Nginx 主动构造帧推送资源，与后端响应无关；它不依赖后端是否支持 HTTP/2
验证是否生效
用 curl 检查客户端到 Nginx 是否走 HTTP/2：
curl -I --http2 https://your-site.com
输出含 HTTP/2 200 即表示成功；浏览器开发者工具 Network 标签页中 Protocol 列显示 h2 也是可靠依据。
至于后端，只要它能正常返回 HTTP/1.1 响应，Nginx 就会将其高效转成 HTTP/2 流交付——你不需要、也无法配置它去“处理后端返回的帧头”。
