Nginx反向代理在日常架构中承担流量入口和回源转发职责。当客户端使用HTTP/2访问Nginx，而Nginx与上游服务器之间也启用HTTP/2时，回源请求同样需要按照RFC 7541进行头部压缩。HPACK算法中的动态表插入决定头部字段能否在后续请求中被高效索引，直接影响回源带宽和上游服务器解析开销。日志系统作为运维排障的主要依据，虽然不直接暴露动态表内部状态，但可以通过组合多个变量还原连接复用与头部压缩的轮廓。
一、回源HTTP/2日志配置与关键字段解读
在Nginx中，回源请求的日志可以通过log_format自定义。默认的combined格式只记录客户端侧信息，要分析回源HTTP/2，需要引入upstream相关变量。常用变量包括$upstream_http_version（上游响应使用的HTTP版本）、$upstream_addr（上游地址）、$upstream_connect_time（建立连接耗时）、$upstream_bytes_sent（发送到上游的字节数）、$upstream_bytes_received（从上游接收的字节数）。其中$upstream_http_version如果显示2.0，说明回源使用了HTTP/2；而$upstream_bytes_sent的变化能反映请求头压缩后的大小。因为HTTP/2头部帧属于控制帧，Nginx在统计发送字节时是否包含头部帧取决于具体版本和模块实现，但在多数情况下，连续请求的发送字节数可以间接体现动态表插入带来的压缩收益。
一个适合分析回源HTTP/2的日志格式可以这样定义：
log_format upstream_http2 '$remote_addr - $upstream_addr - '
'upstream_http_version=$upstream_http_version '
'bytes_sent=$upstream_bytes_sent '
'bytes_received=$upstream_bytes_received '
'connect_time=$upstream_connect_time '
'request_time=$request_time';
access_log /var/log/nginx/upstream_http2.log upstream_http2;
注意变量$upstream_http_version在Nginx 1.9.11之后可用，$upstream_bytes_sent和$upstream_bytes_received在1.11.4后支持。配置完成后，可以收集多个请求的日志，观察同一上游连接上的bytes_sent变化趋势，从而判断动态表是否生效。
需要指出日志中看不到HPACK动态表插入本身，但可以借助连接复用标识推测。Nginx在回源时，如果使用keepalive连接池，多个请求会复用同一条上游HTTP/2连接，动态表可以跨请求累积。如果日志中每个请求的$upstream_addr相同，并且$upstream_connect_time为0（或极小），说明复用了已有连接；此时若发送字节数没有随着请求数增加而下降，可能动态表插入被禁用或者头部字段属于永不索引类别。另外，Nginx还提供了$upstream_http2_stream_id变量（需要Nginx 1.21.0以上或第三方模块），它可以区分同一个HTTP/2连接上的不同流，进一步帮助关联动态表状态变化。
二、HPACK动态表插入机制及其在回源链路中的体现
HPACK（Header Compression for HTTP/2）使用静态表和动态表结合索引头部字段。静态表包含61个常见字段，如:method、:path、content-type等；动态表初始为空，随着连接上的请求和响应头部被处理，新字段会按照编码器策略插入。动态表有最大容量限制，由SETTINGS_HEADER_TABLE_SIZE协商，Nginx作为客户端时可以通过http2_max_field_size和http2_max_header_size等指令间接影响。当Nginx回源发送请求时，它会将请求头转换为HTTP/2头部帧，如果某个头部字段已经在动态表中，则只需发送索引号；如果不在表中，则可以选择使用增量索引、无索引或永不索引表示。选择增量索引意味着该字段会被插入动态表，供后续请求使用。
在回源链路上，动态表插入的效果与连接生命周期强相关。由于动态表存储在连接级别，Nginx与上游之间的HTTP/2连接一旦关闭，动态表就会清空。如果Nginx配置了较短的keepalive_timeout，或者上游主动断开连接，那么即使单次连接内插入大量字段，也无法在下一个连接中复用。因此，观察Nginx日志中$upstream_connect_time为0的请求密度，可以估算连接复用率。一个典型的异常模式是：所有请求的connect_time都大于0，说明每次回源都新建TCP连接和HTTP/2会话，动态表插入几乎无效，头部压缩退化为静态表甚至无压缩。此时应检查upstream块中的keepalive指令和keepalive_timeout配置。
下面给出一个用nghttp检查上游HTTP/2动态表状态的示例。nghttp可以发送多个请求并显示头部帧大小：
nghttp -v --no-dep --header='x-custom-header: value123' https://upstream.ipipp.com/api/test nghttp -v --no-dep --header='x-custom-header: value123' https://upstream.ipipp.com/api/test
两次请求中，第一次头部帧可能包含完整的头部字段，第二次如果动态表插入成功，头部帧会显著变小，且日志中会显示indexed或literal with incremental indexing。结合Nginx回源日志的bytes_sent变化，可以验证动态表插入是否按预期工作。
三、利用日志定位动态表插入异常与优化实践
当Nginx回源HTTP/2链路出现头部压缩效率低下的问题时，通常表现为上游带宽占用偏高、请求头传输耗时增加。通过日志分析，可以从三个维度定位：一是连接复用率，二是发送字节数的趋势，三是响应头大小与请求头的比例。如果同一上游连接上的连续请求发送字节数没有下降，同时响应头大小保持稳定，可能动态表插入未被触发。常见原因包括：头部字段被标记为敏感字段（如Authorization、Cookie有时会被策略跳过索引）、Nginx与上游之间的HTTP/2设置中头部表大小过小、或者上游实现不完整导致动态表更新失败。
针对这些问题，可以调整Nginx配置来优化动态表插入。首先确保upstream块中配置了keepalive和keepalive_timeout，让HTTP/2连接能够持续存活。例如：
upstream backend_http2 {
server 192.168.1.10:443;
keepalive 16;
keepalive_timeout 60s;
}
server {
listen 443 ssl http2;
location / {
proxy_pass https://backend_http2;
proxy_http_version 2.0;
proxy_set_header Connection "";
}
}
proxy_http_version 2.0强制Nginx使用HTTP/2回源，proxy_set_header Connection ""避免转发keep-alive头干扰。keepalive 16指定每个worker保持的空闲连接数，keepalive_timeout 60s延长连接生命周期，让动态表有更多时间累积。同时可以通过http2_max_field_size和http2_max_header_size调整头部大小限制，确保大型Cookie或自定义头不会被强制以无索引方式发送。需要注意的是，动态表容量越大，压缩效果越好，但会消耗上游内存，需要根据实际头部分布权衡。
除了配置优化，还可以通过抓包工具深入分析HPACK动态表插入过程。使用Wireshark过滤http2.header.type==1可以捕获头部帧，查看每个帧中的索引表示。如果发现大部分头部字段都使用literal without indexing或never indexed，说明动态表插入被绕过，需要检查头部字段名是否包含在Nginx的敏感头列表中，或者上游是否通过SETTINGS_HEADER_TABLE_SIZE将表容量限制为0。结合Nginx日志中的连接复用信息和发送字节数，可以形成完整的排障闭环。
Nginx日志本身不会输出HPACK动态表插入的细节，但通过合理配置upstream相关变量，并从连接复用、字节趋势和头部帧行为三个层面交叉验证，完全能够定位动态表插入异常。对于运维和开发人员来说，理解HPACK动态表在回源HTTP/2连接中的生命周期，是优化反向代理性能的重要一环。
Nginx日志HTTP/2 HPACK动态表插入修改时间：2026-10-05 04:13:49