HTTP/2 的多路复用和头部压缩让反向代理架构的行为变得更加复杂。Nginx 在面向客户端时可以使用 HTTP/2，在回源时同样可以配置 HTTP/2，于是同一个请求在代理节点上会经历一次 HPACK 解码和一次重新编码。日志系统记录的是解码后的请求头，但上游服务实际收到的是另一条 HTTP/2 连接上的编码结果。这种差异使得单看 Nginx 日志很难判断头部压缩的动态表是否正常工作。RFC9370 作为 HPACK 的更新版本，重新定义了动态表大小更新和编码器同步细节，成为理解这一过程的重要依据。
Nginx回源HTTP/2时两套HPACK动态表如何协作
在典型的反向代理架构中，客户端到 Nginx 的连接和 Nginx 到上游服务的连接是相互独立的。即使两端都使用 HTTP/2，它们各自的 HPACK 动态表也不会共享。Nginx 从客户端连接读取头部块时，会根据客户端连接的动态表进行解码，还原出完整的请求头字段；随后 Nginx 将这些字段交给回源模块，在新建或复用的上游 HTTP/2 连接上重新编码。该过程会重新计算索引、判断是否加入上游动态表，因此日志中看到的头字段顺序不一定等于上游连接中的编码顺序。
举个例子，如果客户端发送 :method、:path、user-agent，Nginx 日志会原样记录这些字段。但回源时 Nginx 可能插入 X-Forwarded-For、X-Real-IP 等附加头，这会改变头部列表。动态表对重复出现的字段最为敏感，第二个请求开始时，上游连接的动态表已经包含某些字段的映射，Nginx 的编码器会优先使用索引表示，而不会再次发送完整字段名和值。
下面的配置展示 Nginx 如何对上游启用 HTTP/2 回源。注意 proxy_http_version 需要显式设置为 2.0，否则默认仍为 HTTP/1.1。
server {
listen 443 ssl http2;
server_name ipipp.com;
ssl_certificate /etc/nginx/ssl/server.crt;
ssl_certificate_key /etc/nginx/ssl/server.key;
location / {
proxy_pass https://backend;
proxy_http_version 2.0;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
}
RFC9370对动态表更新的核心调整
RFC7541 定义了 HPACK 的静态表、动态表和霍夫曼编码，但对动态表大小更新指令的处理存在一些模糊空间。RFC9370 在保持基本编码结构不变的前提下，强化了动态表大小更新的同步要求。例如，编码器在收到新的 SETTINGS_HEADER_TABLE_SIZE 后，必须在下一个头部块之前发出大小更新指令；解码器在遇到动态表大小更新时，需要调整表容量并驱逐条目，不能依赖连接两端隐式对齐。
这项调整对 Nginx 回源 HTTP/2 的影响很直接。Nginx 作为上游连接的编码器时，需要根据上游通告的 SETTINGS 值控制动态表大小，不能超过对方允许的容量；作为客户端连接的解码器时，又要正确解析客户端发来的大小更新指令。如果 Nginx 版本较旧或第三方模块未完全实现 RFC9370，可能出现动态表容量不一致，导致头部块解码失败，表现为上游返回 502 或连接被重置。
实际抓包中，可以通过 Wireshark 过滤 http2.type == 1 查看 HEADERS 帧，以及过滤 http2.type == 4 查看 SETTINGS 帧。重点关注 SETTINGS_HEADER_TABLE_SIZE 的值和 HEADERS 帧中是否出现了动态表大小更新指令。该指令在 HPACK 头部块中通常占用 5 到 6 个字节，很容易被误认为是普通的索引字段。
从Nginx日志排查HPACK动态表相关异常
Nginx 日志默认使用 combined 格式，只记录请求行、状态码和引用来源，并不会输出完整请求头。要排查回源 HTTP/2 的头部问题，需要自定义日志格式，把关键头字段打印出来。例如使用 $http_user_agent、$http_accept_language 和 $http_x_custom 记录客户端发送的相关头部值，这些值来自 Nginx 对客户端 HTTP/2 头部块的解码结果，因此可以验证客户端侧动态表解码是否正常。
下面是一个便于排查的日志格式配置。Nginx 会在每次请求时输出客户端地址、请求方法、URI 以及几个自定义头字段。
log_format h2debug '$remote_addr [$time_local] "$request" '
'ua="$http_user_agent" '
'custom="$http_x_custom" '
'status=$status';
access_log /var/log/nginx/h2debug.log h2debug;
如果日志中 $http_x_custom 的值总是为空，但客户端确实发送了该字段，就要考虑客户端 HPACK 解码是否成功，或者该字段在回源前被 Nginx 过滤。此时需要对比上游服务实际接收到的头字段。上游可以在应用层打印请求头，或者在 Nginx 上游侧抓包查看 HEADERS 帧。由于回源 HTTP/2 会重新编码，上游抓包看到的头部块不会与客户端侧头部块相同，但解码后的字段应当一致。如果出现字段缺失，大概率是回源编码时动态表索引映射错误，可以尝试降低 http2_max_field_size 或关闭上游连接的动态表复用。
动态表大小与回源性能的调优建议
动态表越大，头部压缩率越高，但内存占用和 CPU 开销也越大。Nginx 提供 http2_max_header_size 和 http2_max_field_size 等指令限制单个头部块大小，同时在回源连接建立时会根据上游 SETTINGS 帧协商动态表大小。多数情况下，保持默认值即可获得较好的压缩与稳定性平衡；但如果上游服务在 SETTINGS_HEADER_TABLE_SIZE 中通告的值过小，而 Nginx 仍然尝试插入大量头部字段，会触发频繁的表驱逐，降低压缩收益。
对于纯内部网络的高吞吐回源场景，可以适当增大上游 HTTP/2 的动态表容量，例如在上游服务中配置较大的 SETTINGS_HEADER_TABLE_SIZE。Nginx 本身作为上游服务器时，可以通过 http2_max_requests 控制连接复用次数，避免动态表在连接后期因长时间运行而膨胀。日志中如果发现大量 431 状态码，说明请求头总大小超过限制，需要检查 large_client_header_buffers 以及上游的动态表容量是否过小。
RFC9370 要求编码器在动态表大小减小时立即驱逐条目，这有助于防止内存无节制增长。运维人员可以通过监控 Nginx 回源连接的平均存活时间和上游内存占用，判断动态表是否带来额外压力。若回源连接频繁重建，压缩收益会大打折扣，此时保持长连接比单纯调大动态表更有效。Nginx 配置中的 keepalive 和 keepalive_requests 指令同样适用于 HTTP/2 回源连接池，合理的连接复用策略能显著提升头部压缩的整体命中率。
Nginx日志回源HTTP/2 HPACK动态表RFC9370修改时间：2026-09-23 16:50:27