HTTP/2的头部压缩机制消除了大量冗余头部传输，但也引入了一个脆弱的状态同步问题——HPACK动态表。Nginx在反向代理回源时如果开启了HTTP/2，它同时扮演客户端角色与上游服务协商动态表，此时任何一端对RFC7541的轻微偏离都可能引发难以解释的请求失败。下面结合Nginx日志体系分析如何定位这类问题。
一、Nginx回源启用HTTP/2与HPACK动态表的关系
Nginx默认使用HTTP/1.1回源，即使客户端通过HTTP/2访问Nginx，Nginx与上游服务之间仍然是独立的HTTP/1.1连接。这种默认行为天然绕开了HPACK动态表在回源链路中的同步问题。但为了减少上游连接数、降低头部开销，不少团队会配置proxy_http_version 2.0;让Nginx与上游服务也走HTTP/2。一旦启用，Nginx会为每一条上游连接维护独立的HPACK编码器和解码器，动态表的大小、更新指令、索引状态都必须在连接持续期间严格一致。
HPACK动态表本质上是一个先进先出的头部字段索引表，初始为空，容量由SETTINGS_HEADER_TABLE_SIZE决定。RFC7541规定动态表可以保存完整的头部名称和值，后续只需要发送索引号即可还原。动态表容量变化通过动态表大小更新指令触发，如果发送端和接收端对容量上限理解不一致，就会出现索引越界或解压失败。例如上游服务认为动态表容量为4096字节，Nginx却按照默认4096字节维护，但某次插入项超过了剩余空间，双方必须同步执行驱逐策略。任何日志中没有直接显示这个状态，但可以通过请求失败模式间接判断。
配置示例：
# Nginx 回源启用 HTTP/2
location /api/ {
proxy_pass https://upstream;
proxy_http_version 2.0;
proxy_set_header Connection "";
proxy_set_header Host $host;
}
注意proxy_set_header Connection "";这一行虽然主要用于HTTP/1.1长连接，但在HTTP/2模式下也建议保留，避免某些上游误解析Connection头。更多关于HPACK动态表的行为无法通过这个基础配置直接观测，需要结合日志变量进一步分析。
二、Nginx日志中能直接看到哪些HPACK相关信号
Nginx默认的combined日志格式只记录访问路径、状态码、响应大小等基础信息，对于HPACK动态表错误通常只会给出笼统的上游错误提示。例如上游返回400 Bad Request或431 Request Header Fields Too Large，Nginx的$upstream_status会显示这些状态码，但真正的解压失败可能发生在Nginx解析上游响应头或者上游解析Nginx请求头阶段。此时error.log中可能出现upstream sent invalid header或http2 upstream header invalid之类记录，具体内容取决于编译的模块和错误级别。
要获得更细粒度的HPACK动态表信息，最有效的做法是在Nginx中提升debug日志级别，特别是在与上游建立HTTP/2连接时启用error_log /var/log/nginx/error.log debug;。Nginx的HTTP/2模块在debug级别会输出帧类型、流ID、动态表更新指令等关键事件。比如一条动态表插入操作对应http2: HEADERS frame中的table size update，如果后续索引引用出错，日志会连续出现http2: invalid dynamic table index。这些内容不是标准变量，只能通过debug日志捕获。
另一个可以扩展的日志字段是$upstream_http_*变量。例如记录上游返回的content-encoding、content-type可以帮助排除业务层错误，但与HPACK无直接关系。真正能用变量表达的是$request_length和$upstream_header_time。当动态表同步失败导致反复重试或压缩效率极端下降时，请求长度会异常增大，头部解析时间也会明显拉长。建议在log_format中增加这两个字段，配合状态码一起观察：
log_format hpack_debug '$remote_addr - $status - req_len:$request_length - up_hdr_time:$upstream_header_time - up_status:$upstream_status - uri:$request'; access_log /var/log/nginx/hpack_debug.log hpack_debug;
这个日志格式不会直接告诉你动态表哪里错了，但能帮助你判断是否属于头部压缩层问题。如果同一个URI在正常时$request_length只有400字节，故障时膨胀到2000字节以上，而状态码变成431，基本可以锁定HPACK动态表或头部大小限制附近。
三、RFC7541动态表的核心规则与排查思路
RFC7541为HPACK定义了静态表和动态表两部分。静态表固定61项，包含常见的:method GET、:path /等，索引从1到61；动态表从62开始，内容由连接双方在通信过程中逐步插入。动态表有一个最大容量，由HTTP/2 SETTINGS帧中的SETTINGS_HEADER_TABLE_SIZE参数协商。默认值为4096字节，但两端可以不同，实际生效值取发送方和接收方中的较小值。动态表的每次插入都计算头字段名称长度加值长度再加32字节开销，如果超出剩余容量，就必须从队首驱逐旧条目。
排查动态表问题最核心的一点是确认双方协商的容量是否一致。Nginx作为客户端时会向上游发送自己的SETTINGS，同时接收上游的SETTINGS。如果上游实现偏离RFC7541，例如把动态表容量修改指令放在HEADERS帧之后，或者忽略容量更新后未驱逐旧项，都可能导致Nginx解压时索引指向不存在的位置。这种情况在Nginx的debug日志中会出现http2: table size update之后紧接着http2: invalid header index。此时可以用tcpdump抓取回源连接，过滤HTTP/2帧进行分析：
tcpdump -i eth0 -s 0 -A 'tcp port 443 and host upstream.ippipp.com' -w h2.pcap
抓包后使用支持HTTP/2解析的工具查看SETTINGS帧和HEADERS帧的细节。重点核对三个字段：SETTINGS_HEADER_TABLE_SIZE值、HEADERS帧中的动态表大小更新指令、以及实际引用的索引号是否在动态表有效范围内。正常请求中索引号会稳定在62到150之间，如果日志显示引用了超出当前容量的索引，说明发送方没有正确执行驱逐。
另一个常见问题是HPACK的霍夫曼编码虽然不直接关联动态表，但在动态表插入项时如果字符串编码错误，也会表现为解压失败。RFC7541附录B给出了完整的霍夫曼码表，Nginx内部使用ngx_http_v2_huff_decode_bits函数解码，一旦失败会记录http2: huffman decoding error。遇到这种日志时，优先检查上游服务使用的HTTP/2库版本，某些老版本的Node.js或Go实现存在霍夫曼编码边界错误。
四、日志增强与监控建议
针对Nginx回源HTTP/2的HPACK动态表问题，不建议只依赖默认日志。推荐在全局或特定location中配置专门的log_format，将$upstream_status、$upstream_header_time、$request_length、$request_time、$upstream_addr、$upstream_http2_stream_id（如果模块支持）全部记录下来。其中$upstream_http2_stream_id在部分Nginx版本中并不存在，可以用$upstream_http2_stream_id尝试性配置，若变量为空则说明当前编译模块未暴露该值，可改用$upstream_http2或忽略。
除了Nginx自身日志，配合OpenResty的Lua能力可以在日志阶段直接读取HTTP/2连接的内部状态，但不建议在生产环境为了日志引入过重依赖。更稳妥的方案是启用Nginx的error_log debug_http2级别，并配合日志轮转控制体积。debug日志只建议在出现持续431或解压错误时短时开启，定位完成后恢复info级别。下面给出一个可选的错误日志配置：
error_log /var/log/nginx/error.log debug;
# 仅对特定server块开启debug
server {
listen 443 ssl http2;
error_log /var/log/nginx/h2_debug.log debug_http2;
}
如果经过日志和抓包确认是上游服务的HPACK实现问题，可在不改Nginx的情况下临时回退到HTTP/1.1回源作为应急手段。将proxy_http_version改回1.1即可完全绕开HPACK动态表问题，但会损失头部压缩收益。长期方案应当推动上游修复RFC7541兼容性，或者更换可靠的HTTP/2库。
日常监控中还可以对$upstream_header_time设置阈值告警。当头部解析时间超过正常基线的三倍并伴随431状态码，大概率是HPACK动态表同步异常。结合Nginx的access日志聚合统计，可以快速发现是某个上游实例还是所有实例都出现问题。HPACK动态表问题往往只影响特定连接，因此日志中需要保留$upstream_addr字段，帮助定位到具体实例。