在 Nginx 反向代理配置中，将回源连接升级到 HTTP/2 后，访问日志里看到的响应头常与源站应用实际返回的值不同。自定义头字段可能消失，大小写会从 Mixed-Case 变为 lowercase，某些值甚至显示为空。这个现象经常被误解为 Nginx 日志采集逻辑在处理 HTTP/2 时出现缺陷，但真正的原因通常来自 HTTP/2 的头部压缩协议 HPACK 以及动态表状态。要理解这一层差异，需要先明确 Nginx 日志记录的是 HPACK 解码之后的头部内容，而不是线上的二进制帧。
一、HTTP/2 回源连接中的 HPACK 动态表如何变化
HPACK 是 HTTP/2 用来压缩头部字段的协议，核心定义在 RFC 7541。编码器维护两张表：静态表包含 61 个常见字段，例如 :method: GET、:status: 200、content-type 等；动态表初始为空，由连接双方在交互中逐步填充。动态表具有连接级生命周期，关闭连接后表内容失效。Nginx 作为回源客户端时，会为上游连接创建编码器和解码器，编码器负责压缩发送给源站的请求头，解码器负责还原源站返回的响应头。动态表每次新增条目，都可能改变后续头部块的编码结果。比如第一次请求包含自定义头 X-Request-Id，该字段被加入动态表后，第二次携带相同字段时可能只编码为一个动态表索引，而不是完整字符串。
在排查日志时，这个机制说明了一个关键问题：日志里看到的头部值不是原始编码字节。Nginx 访问日志变量 $upstream_http_ 系列读取的是解码后的头部值。对于同一个响应，抓包工具可能显示 Header Block Fragment 中的索引号 62，而日志显示完整字符串 /api/v1/users。二者并不矛盾，因为抓包看到的是压缩后的二进制索引，日志看到的是 HPACK 解码器根据本地动态表还原后的内容。如果动态表内容不同，同一个索引号可能对应完全不同的头部名称或值，这也是距离源站连接状态最容易产生误解的地方。
另外，有人会把 RFC 10000 当作 HPACK 规范编号，实际在 IETF 文档中，HTTP/2 头部压缩对应 RFC 7541，HTTP/2 整体协议由 RFC 9113 维护。RFC 10000 并不在这些规范链路上，遇到这个编号通常需要回到 RFC 7541 查看 HPACK 的动态表更新、索引地址空间和 Huffman 编码规则。
二、Nginx 日志字段为什么与源站响应头不一致
Nginx 回源启用 HTTP/2 的前提是 proxy_http_version 设置为 2.0。虽然 HTTP/2 在传输层不再区分大小写，但规范要求头部名称全部使用小写。源站应用可能返回 X-Request-Id 这样的混合大小写，经过 HTTP/2 编码后必须转换为 x-request-id。Nginx 在构造 $upstream_http_x_request_id 变量时，会统一采用小写加下划线的方式，所以日志中看到小写字段是协议约束，而不是 Nginx 做了额外的强制转换。如果源站直接在 HTTP/1.1 中返回混合大小写，Nginx 的 HTTP/1.1 变量逻辑可能会保留名称，但 HTTP/2 回源不会出现这种情况。
下面的配置展示了如何让 Nginx 以 HTTP/2 连接上游，并记录回源协议版本、响应状态和头部解码耗时：
log_format h2upstream '$remote_addr - $upstream_addr '
'proto=$upstream_protocol '
'status=$upstream_status '
'header_time=$upstream_header_time '
'request_id=$upstream_http_x_request_id '
'cache_status=$upstream_cache_status';
access_log /var/log/nginx/h2upstream.log h2upstream;
server {
listen 443 ssl;
http2 on;
location /api/ {
proxy_http_version 2.0;
proxy_pass https://backend.ipipp.com;
proxy_set_header Connection "";
proxy_set_header X-Request-Id $request_id;
}
}
在这个配置中，$upstream_http_x_request_id 来自 Nginx 对上游响应头的 HPACK 解码结果。如果源站没有返回 X-Request-Id，该变量为空；如果响应头通过动态表索引引用，解码后仍然会输出完整值。日志并不会展示 HPACK 的索引号或 Huffman 编码，因为那些信息在解码阶段已经完成使命。因此当有人希望通过访问日志还原线上头部块字节流时，这种期望本身就不符合 Nginx 的日志设计。
动态表大小还会影响头部压缩比。源站可以在 SETTINGS 帧中设置 SETTINGS_HEADER_TABLE_SIZE，限制对端编码器可使用的动态表容量。若该值设置过小，动态表空间不足，编码器需要频繁驱逐旧条目，压缩效率下降，传输字节数增加。Nginx 回源时看到的 $upstream_header_time 可能因此变高，但访问日志里的头部值不会变化，因为解码结果相同。
一个常见误区是检查 $upstream_http_content_encoding 时发现值为空，便认为源站没有返回压缩后的响应体。实际上如果源站通过 HTTP/2 返回 content-encoding: gzip，Nginx 的解码器会将该头部写回变量。若出现空值，应当先确认源站是否真的返回该字段，再排查 Nginx 是否关闭了 upstream 头部解析，而不是怀疑 HPACK 动态表吞掉了字段。
三、结合错误日志与抓包定位动态表状态异常
HPACK 动态表的状态不同步会导致连接级错误。Nginx 作为 HTTP/2 客户端时，如果上游发送的头部块引用了一个不存在的动态表索引，Nginx 会记录类似 invalid header block 的错误并关闭连接。这类错误通常不是日志变量缺失，而是整个响应读取失败。要观察这一过程，可以把 error_log 调整为 debug 级别，但生产环境建议只对特定 server 短暂开启。错误日志中会出现 upstream sent invalid header 或 http2 header block 相关描述，指向 HPACK 解码失败。
抓包是确认 HPACK 编码过程的直接手段。可以在 Nginx 与上游之间的网卡上抓取流量，然后使用支持 HTTP/2 解析的工具查看 SETTINGS 帧和 HEADERS 帧。一个简单的抓包命令如下：
tcpdump -i eth0 -s 0 -w /tmp/h2_origin.pcap tcp port 443
抓包后，在分析工具中过滤 http2 或 hpack 相关帧。重点检查 SETTINGS_HEADER_TABLE_SIZE 的值，以及 HEADERS 帧中是否包含动态表索引、增量索引更新或字面量字段。如果看到日志缺失某个头部，而抓包显示该头部使用动态表索引编码，可以继续观察连接建立后是否发生过 HTTP/2 ping 或 GOAWAY 帧，这些事件可能让动态表提前失效。
另一种定位思路是在上游服务器上记录 HTTP/2 状态。由于动态表在连接断开后消失，某些问题只在长连接复用期间出现。通过 keepalive 指令配置的连接缓存可以让 HTTP/2 连接被复用；即便不配置 keepalive，HTTP/2 本身的多路复用也能让多个请求共用一个连接。若某个上游连接维持过久，动态表可能已经累积了大量条目，这时新请求的压缩行为与首请求完全不同。通过访问日志中的 $upstream_addr 和 $upstream_protocol 能够定位到具体连接，再结合抓包会话，往往能快速确认是否因动态表状态不同步导致。
最后需要强调，RFC 7541 对动态表的最大容量、索引切分和驱逐策略有明确要求，而 HTTP/2 实现之间对这些细节的差异可能触发互操作问题。Nginx 日志只能反映解码后的结果，不能直接展示 HPACK 动态表的内部状态。如果日志正常但业务异常，可以优先检查源站实现是否正确遵循 RFC 7541 和 RFC 9113，而不是试图从 Nginx 访问日志中反推压缩字节流。
Nginx日志回源HTTP/2 HPACK动态表修改时间：2026-09-21 03:04:57