把Nginx前面的接入层升级到HTTP/2之后，一个隐蔽的坑开始浮出水面：回源请求的日志出现异常，部分请求头莫名丢失，甚至偶发502。这类问题往往不是配置写错，而是与HTTP/2的头部压缩机制HPACK密切相关，尤其是动态表的插入、引用和删除逻辑。要理解问题根源，需要先搞清楚Nginx在回源链路中扮演的角色，以及HPACK动态表是如何在连接级别被共享的。
一、Nginx回源时到底用的是什么协议
首先要明确一个事实：在绝大多数场景下，Nginx通过proxy_pass回源时，默认走的是HTTP/1.1（早期版本默认是HTTP/1.0，需要显式声明proxy_http_version 1.1）。也就是说，即使你的监听端口配置了listen 443 ssl http2，那只影响客户端到Nginx这一段，Nginx到上游之间依然是另一条独立连接。很多运维同学看到日志里上游协议显示不对，第一反应是去检查TLS证书，其实方向就错了。
判断回源协议最直接的办法是抓包。在Nginx所在机器上执行tcpdump，观察与上游端口的握手过程，或者在日志格式里加入$upstream_http_相关变量做旁证。如果上游确实是HTTP/2（例如某些云厂商的网关、gRPC服务），而Nginx侧配置不当，就会出现协议不匹配，表现为请求被拒或响应解析失败。
对于gRPC这类强依赖HTTP/2的场景，Nginx提供了专门的grpc_pass指令，它内部使用与HTTP/1.1回源完全不同的解析器和连接管理逻辑。混用proxy_pass和gRPC后端是常见的翻车点，务必分开对待。
二、HPACK动态表的工作原理与删除机制
HTTP/2使用HPACK压缩头部字段，目的是减少重复头部的传输开销。HPACK的压缩状态由两部分构成：静态表（61个预定义的常用头部）和动态表。动态表是一个先进先出的环形结构，每个新的头部字段通过literal header field with incremental indexing指令插入表头部，同时获得一个索引。后续请求如果再次出现相同字段，只需要发送一个字节的索引即可。
关键点在于：动态表是连接级别的状态，不是请求级别的。同一条HTTP/2连接上的所有流共享这一张表。表有容量上限，由双方通过SETTINGS_HEADER_TABLE_SIZE帧协商（默认4096字节）。当插入新条目导致总大小超过上限时，最旧的条目会被驱逐——这就是所谓的动态表删除。被驱逐的条目所对应的索引会被后续新条目复用。
# HPACK动态表生命周期示意 插入: :path=/api/user -> 分配索引 62 插入: authorization=Bearer x -> 分配索引 63 插入: 超大cookie(占用3500字节) -> 索引62被驱逐(删除) 此时若客户端仍引用索引62 -> 服务端解码出错误字段或报COMPRESSION_ERROR
如果客户端发出的索引引用了一个服务端已经驱逐的条目，双方压缩状态失步，服务端会直接返回COMPRESSION_ERROR并关闭连接。在Nginx日志上，这类错误往往表现为上游连接突然断开、502 Bad Gateway，而且时间点与流量高峰重合——高峰期请求头更多、更大，动态表驱逐更频繁。
另一个容易踩的坑是SETTINGS_HEADER_TABLE_SIZE的动态更新。一方可以中途发送SETTINGS帧缩小表容量，接收方必须立即执行驱逐操作以符合新上限。某些中间件或CDN节点会在连接空闲后调整表大小，如果Nginx侧没有正确处理这一帧，后续复用连接时就会出现解码错乱。排查时可以在日志中开启info级别，观察是否有http2相关的连接关闭记录。
三、连接复用、并发流与日志错乱
理解了动态表是连接级别的状态，就能解释一类诡异现象：日志里某个请求的头部内容“串”到了另一个请求上。HTTP/2允许多路复用，一条连接上同时跑几十个流，HPACK动态表在编码时依赖流的处理顺序而非发送顺序。当存在乱序发送时，发送方必须使用动态表大小更新指令来同步状态，否则接收方的索引对应关系就会错位。
Nginx的HTTP/2模块在实现上遵循了这一规范，但一些非标准的上游实现（尤其是某些自研网关）没有正确处理动态表大小更新，导致在特定流量模式下稳定复现。如果怀疑是这种情况，可以临时关闭上游的HPACK压缩验证：让上游把SETTINGS_HEADER_TABLE_SIZE设为0，所有头部改为字面量发送，问题消失即可确认压缩失步是根因。
# 在Nginx上抓取与上游之间的流量，过滤HTTP/2帧 tcpdump -i any -w http2.pcap host upstream.example.ip and port 443 # 使用nghttp解析帧，观察SETTINGS与HPACK动态表操作 nghttpd -v --no-tls 8443 # 常见定位线索： # 1. SETTINGS帧中HEADER_TABLE_SIZE被中途修改 # 2. 发送方未插入却引用了索引 # 3. GOAWAY帧携带COMPRESSION_ERROR错误码
日志层面，建议在log_format中加入$upstream_status、$upstream_connect_time和$upstream_header_time。如果看到大量请求的$upstream_status为空但耗时正常，多半是连接在HPACK解码阶段就被重置了，请求根本没能到达上游应用层。
四、规避方案与配置建议
最稳妥的规避方式是让Nginx回源继续使用HTTP/1.1，仅在接入层暴露HTTP/2。HTTP/1.1没有连接级别的共享压缩状态，每个请求头部独立解析，天然不存在动态表失步问题。对于普通的反向代理、静态内容分发场景，这样做的性能损失几乎可以忽略。
# 回源固定使用HTTP/1.1，保持长连接
upstream backend {
server 10.0.0.10:8080;
keepalive 64; # 启用回源长连接池
}
server {
listen 443 ssl http2; # 对客户端提供HTTP/2
location / {
proxy_pass http://backend;
proxy_http_version 1.1; # 回源协议显式声明
proxy_set_header Connection ""; # 清除Connection头以复用连接
}
}如果业务必须回源HTTP/2（例如上游是gRPC或强依赖server push），则要注意几点：第一，使用grpc_pass而不是proxy_pass；第二，确保Nginx版本较新，早期版本对HPACK动态表大小更新指令的处理存在缺陷；第三，压测时用真实的大头部集合（长Cookie、多段Authorization）去触发动态表驱逐，而不是只测小请求。
最后，监控方面建议对upstream的连接重置次数单独打点。HTTP/2连接一旦因为压缩错误被关闭，该连接上排队的所有流都会失败，影响面远大于HTTP/1.1的单请求失败。把$upstream_addr和错误码关联分析，可以在动态表问题演变成大面积故障之前提前发现异常模式。
总结一下排查思路：先确认回源协议与预期一致，再检查是否出现COMPRESSION_ERROR，然后通过禁用HPACK动态表做对照实验，最后落地为连接策略或版本升级。HPACK本身是精巧的设计，问题往往出在非标准实现与复杂流量模式的组合上，理解了动态表这条主线，这类日志异常就不再无从下手。