一位同事反馈线上Nginx偶发502，查看error日志时发现了一段完全看不懂的内容：本该是Host、User-Agent这类请求头的位置，出现了一串十六进制字节。更奇怪的是，同一时刻access日志里记录的$request_body和$upstream_status也明显对不上号。折腾了一下午才定位到，问题出在回源链路启用了HTTP/2，而HPACK动态表在连接异常时的状态错乱，让Nginx解析出了完全错误的头部数据。这篇文章把这个机制和排查思路完整梳理一遍。
HPACK到底是什么，为什么它会污染日志
HTTP/2为了解决HTTP/1.1中请求头冗余的问题，引入了HPACK压缩算法。它由三部分组成：静态表、动态表和哈夫曼编码。静态表预先定义了61个常见的键值对，比如index为2的行对应:method: GET；动态表则是在连接生命周期内，双方把各自发送过的请求头按FIFO顺序缓存起来，后续相同的内容只需传一个索引号即可。
关键就在这个动态表上。它是有状态的，客户端和服务端各自维护一份镜像，靠连接上传输的字节流保持同步。一旦某个环节丢了一段数据，或者连接两端对动态表大小的理解出现偏差，后续所有基于索引的头部还原就全部错位。表现出来就是：明明客户端发的是Accept-Encoding: gzip，服务端解出来的却是另一个头，甚至是一段乱码字节。Nginx在记录错误日志时会把解析失败的原始帧内容打出来，这就是我们看到的十六进制串。
用简单的伪代码描述一下解压过程：
// HPACK解码单个头部的基本逻辑
if (is_indexed(buf)) {
// 直接用索引查表，索引错位则返回错误内容
index = read_integer(buf, 7);
return lookup(index, static_table, dynamic_table);
}
if (is_literal_with_incremental_indexing(buf)) {
// 字面量头部，解码后插入动态表
name = decode_string(buf);
value = decode_string(buf);
dynamic_table_add(name, value);
return (name, value);
}注意dynamic_table_add这一步：每次插入都会改变动态表的索引基准。如果Nginx与上游之间有一条连接走了这条路，而另一条没走，两条连接的状态就是不同的，任何跨连接复用解压上下文的行为都会产生错乱。
什么场景下会触发，为什么日志看起来毫无规律
最常见的触发场景是上游服务器异常重启或被LVS/F5强制踢掉连接。HTTP/2回源通常基于长连接复用，Nginx的proxy_http2 on配合upstream模块会维护一条到后端的HTTP/2连接。当这条连接在传输过程中被中间设备静默丢弃，Nginx可能还在往半开连接里写数据，写完后读回执时才发现连接已断，此时error日志会记录upstream prematurely closed connection，而access日志里的$upstream_status则是一个短横线。
第二种场景更隐蔽：上游是自研网关，动态表的实现与标准存在细微差异。比如对 SETTINGS_HEADER_TABLE_SIZE 更新帧的处理顺序不同，导致双方动态表的容量感知不一致，表项被错误驱逐。这种问题表现为低概率出现的头部错乱，且错乱内容每次都不一样，日志里自然毫无规律可循。
第三种是Nginx自身的版本问题。早期版本（如1.9.x到1.13.x的部分分支）对回源HTTP/2的支持并不完善，ngx_http_v2_module在处理上游动态表插入失败时的容错逻辑有缺陷，可能把未完全解码的头部直接透传给日志模块。排查前先确认版本：
nginx -v # 查看编译参数，确认是否带http_v2模块 nginx -V 2>&1 | tr ' ' '\n' | grep -i v2 # 查看与上游之间实际协商的协议 tcpdump -i eth0 -A 'tcp port 443 and host 10.0.0.8' -w h2.pcap
抓包后用Wireshark打开，过滤http2协议，重点看SETTINGS帧和HEADERS帧中的HPACK字段。如果发现双方对动态表大小的声明不一致，基本可以锁定问题。
排查步骤与规避方案
建议按固定顺序排查：第一步看error日志的时间点是否与上游发布、重启记录吻合；第二步对比异常请求与正常请求的$connection和$upstream_connect_time，确认是否集中在同一条复用连接上；第三步用抓包验证HPACK解码是否错位。如果确认是动态表问题，有几种处理思路。
最直接的是回源降级到HTTP/1.1，牺牲一点头部压缩的收益，换来链路的简单可靠。Nginx默认回源就是HTTP/1.0或1.1，只有显式配置proxy_http2 on才会走HTTP/2，去掉这行配置即可。如果上游压力不大、单请求头部体积有限，这个方案性价比很高。
如果必须保留HTTP/2回源，可以调整连接的稳定性参数，减少半开连接和状态错乱的概率：
upstream backend {
server 10.0.0.8:443;
# 缩短空闲连接存活时间，降低半开连接概率
keepalive_timeout 30s;
# 限制单连接最大请求数，定期重建连接让动态表归零
keepalive_requests 1000;
}
server {
listen 443 ssl http2;
location / {
proxy_pass https://backend;
proxy_http_version 1.1;
# 若确需HTTP/2回源则开启，并确保上游实现规范
# proxy_http2 on;
proxy_set_header Connection "";
}
}另外，升级Nginx到当前稳定版也很重要，新版本对HTTP/2上游连接的异常处理做了大量修补。最后提醒一点：日志里出现乱码不一定是被攻击，先怀疑协议层的解码问题，把error日志级别调到debug，配合error_log指定单独文件观察原始帧内容，往往比盲目重试更能快速接近真相。