Nginx反向代理与上游源站之间默认使用HTTP/1.1回源，但在面对大量小请求或者需要复用长连接时，启用HTTP/2回源能够明显降低连接建立成本和头部传输开销。不过HTTP/2的头部压缩依赖HPACK算法，其中动态表的更新、索引命中与表大小变化不会记录在常规访问日志里，一旦回源环节出现头部压缩异常或压缩效率下降，分析起来并不直观。要排查这类问题，需要同时打开Nginx的调试日志，并配合抓包工具观察HTTP/2帧中的HPACK编码。
一、Nginx回源HTTP/2的连接配置与日志入口
Nginx从1.25版本开始逐步完善对上游HTTP/2连接的支持，实际使用中可以通过proxy_http_version指令把回源协议切换为2.0。配置很简单，在location或upstream块内指定与上游建立HTTP/2连接，并启用TLS保证安全传输。下面这段配置演示了一个常见的回源场景：
server {
listen 443 ssl;
server_name proxy.ipipp.com;
ssl_certificate /etc/nginx/certs/proxy.crt;
ssl_certificate_key /etc/nginx/certs/proxy.key;
location / {
proxy_pass https://backend.ipipp.com;
proxy_http_version 2.0;
proxy_ssl_server_name on;
proxy_ssl_protocols TLSv1.3;
}
}
这样配置以后，Nginx会优先尝试与上游通过ALPN协商出h2协议。建立HTTP/2连接后，双方会交换SETTINGS帧，其中SETTINGS_HEADER_TABLE_SIZE参数决定HPACK动态表的最大字节数。Nginx作为客户端不会主动修改这个值，它由上游服务器控制。日常查看请求状态时，access_log里只有请求方法、URI、状态码和耗时等字段，并不会记录HPACK动态表的插入、驱逐或索引命中信息。真正的内部诊断信息需要从error_log的debug级别获取。
开启debug日志并不复杂，在Nginx主配置中加入下面这行，并重新加载即可：
error_log logs/error.log debug;
debug级别会输出大量连接建立、SSL握手、HTTP/2帧收发、头部编解码等细节。对于生产环境，全局开启debug会带来明显的磁盘I/O和CPU开销，日志体积也容易失控。更合理的做法是使用debug_connection只对特定来源的调试连接生效，把日志范围限制在需要观察的客户端或上游地址。
二、用debug_connection精准开启HPACK调试输出
debug_connection指令可以放在events块中，指定一个或多个IP地址或网段。只有匹配这些地址的连接才会启用debug级别日志，其他连接仍然保持原有日志级别。这样既能捕获HTTP/2回源调试信息，又不会让整个error_log被淹没。
下面是一个配合HTTP/2回源调试的配置。假设需要观察的客户端来自测试网段192.168.10.0/24，或者关注的上游源站地址是10.0.0.5，可以写成：
events {
debug_connection 192.168.10.0/24;
debug_connection 10.0.0.5;
}
error_log logs/error.log info;
注意debug_connection只影响连接级别的调试信息输出，error_log本身的级别仍然需要设置成debug或更低级别。很多配置里error_log默认是error级别，那样即使debug_connection匹配了地址，也不会出现调试内容。调试日志中与HTTP/2相关的条目通常带有http2或hpack标识，可以用grep快速过滤：
grep -Ei 'hpack|http2|headers' /var/log/nginx/error.log
过滤出来的内容可能包括HTTP/2帧类型、流ID、头部块长度以及HPACK解码过程中的动态表更新事件。实际输出格式会因Nginx版本和编译参数不同而有所差异，有些版本会打印类似http2 hpack dynamic table size的调试行，有些版本则更侧重错误恢复和流状态变化。如果发现日志中缺少HPACK细节，不能只依赖Nginx自身输出，需要借助外部抓包工具查看完整帧内容。
三、抓包解码HPACK动态表变化
HPACK动态表的操作隐藏在HTTP/2的HEADERS帧中。Nginx的调试日志通常只给出摘要信息，想要看到每次动态表插入、索引号选择以及表大小更新，最直接的方式是抓取回源链路的流量并用支持HPACK解码的工具查看。对于明文h2c环境，Wireshark可以直接解析；对于TLS加密的h2流量，需要提前导出会话密钥。Nginx目前没有像浏览器那样便捷的密钥导出接口，但可以通过在测试环境使用明文h2c来简化分析。
假设测试环境上游源站以h2c模式监听，可以执行tcpdump抓取回源流量：
tcpdump -i eth0 -s 0 -w h2-backend.pcap host 10.0.0.5
然后用tshark过滤HTTP/2 HEADERS帧并展开头部压缩详情。如果希望查看HPACK动态表的使用情况，可以观察每个HEADERS帧中的头部块。同一个上游连接中，第一次请求的响应头可能触发动态表插入，后续相同响应头会以索引号或动态表字面量形式发送。例如上游每次都返回Set-Cookie和Cache-Control，这些名字一旦进入动态表，后续请求的头部块体积会显著减小。通过对比前后帧的长度和字段表示方式，可以判断动态表是否按预期工作。
Wireshark中还可以直接查看SETTINGS帧的SETTINGS_HEADER_TABLE_SIZE值，确认上游到底分配了多大的动态表空间。如果该值很小，动态表会频繁发生驱逐，压缩效果自然下降。这个信息在Nginx的debug日志里并不总是清晰，抓包反而更直观。
四、动态表大小协商与优化排查思路
HPACK动态表的大小由连接建立时上游服务器发送的SETTINGS帧决定。Nginx作为回源客户端，目前没有专门指令去设置上游连接使用的动态表大小，因此排查方向通常落在上游源站自身。例如上游是另一台Nginx作为HTTP/2服务器时，可以查看其http2_max_header_size、http2_max_field_size等配置是否合理，但动态表大小并不由这些指令控制。大多数HTTP/2实现会使用默认的4096字节动态表，如果需要更大空间，可能需要修改源站服务器实现或使用支持动态表配置的库。
优化排查时，建议先确认错误日志中是否存在大量HTTP/2头部错误或流重置，然后检查抓包文件里的SETTINGS值。如果动态表空间充足但头部仍然很大，说明响应头中存在过多一次性字段或随机值，这些内容即使进入动态表也无法复用。相反，如果动态表空间过小，固定出现的字段会反复被驱逐和重新插入，增加头部块长度。根据观测结果调整源站响应头的稳定性，或增大动态表空间后再重新测试。
处理完这类问题后，继续保留debug_connection针对少量地址的调试输出是有价值的，它能够在后续变更时快速定位是否由HPACK压缩或HTTP/2帧处理引发。排查HTTP/2回源问题不只看请求状态码，动态表日志和抓包分析才是定位头部压缩异常的有效手段。