Nginx作为反向代理时，回源链路的协议选择往往被当作一个简单的开关来对待：加上proxy_http2 on就认为万事大吉。但HTTP/2带来的不只是多路复用，还有HPACK这种有状态的头部压缩机制。RFC7232规定的条件请求和缓存验证流程，本质上依赖头部字段在整条链路上的无损传递，而HPACK动态表的存在让这个过程多了一层需要仔细审视的环节。本文围绕Nginx回源HTTP/2场景，分析HPACK动态表的工作原理、它与RFC7232验证字段的交互，以及在日志中定位相关问题的方法。
一、HPACK动态表的工作原理与状态同步问题
HPACK是RFC 7541定义的头部压缩算法，核心思想是两端各自维护一张索引表，将重复出现的头部字段编成索引号传输。静态表包含61个常见头部，比如:index 2对应method GET，而动态表则在连接生命周期内不断把新出现的头部字段插入到表头部，老条目被逐步挤出。发送方可以用一个索引号代替完整的“头部名+值”组合，也可以用增量编码只传差量。
问题的关键在于动态表是有状态的。HTTP/1.1的头部是明文逐条发送的，任何一帧解码失败只会影响那一个响应；而HTTP/2中，一旦某个帧的HPACK解码出错，整个连接的压缩状态就失去同步，后续所有流上的头部都可能无法正确还原。Nginx作为中间节点，一边要对上游的HTTP/2响应做HPACK解码，还原成内部表示，另一边对客户端可能还要再按HTTP/2或HTTP/1.1重新编码，这个“解码再编码”的过程中如果出现状态管理问题，头部字段就可能被丢失或改写。
举个具体场景：上游服务器启用了较大的动态表容量，在长连接上连续返回多个API响应，其中ETag字段值较长且每个响应都不同。如果Nginx与上游之间使用了keepalive连接，动态表持续增长，某些只出现一次的长头部反而可能被增量编码为“不插入动态表”的字面量形式。这本身没有错，但如果你在Nginx层用proxy_hide_header或proxy_pass_header做精细控制，就必须清楚哪些头部在解码后仍然完整存在。实践中常见的问题是误以为加了压缩就会丢信息，实际上HPACK是可逆压缩，真正丢信息的是配置层面的干预和协议转换。
二、RFC7232缓存验证字段在代理链路中的传递要求
RFC7232定义了条件请求的完整体系：服务器通过ETag或Last-Modified告诉客户端资源的版本，客户端在下次请求时带上If-None-Match或If-Modified-Since，服务器判断资源未变则返回304。这套机制的前提是验证字段必须端到端一致：客户端看到的ETag，必须是资源真实版本的标识，而不能是中间代理改写过的值。
Nginx在转发上游响应时，默认会传递绝大多数头部，但有几个细节值得注意。第一，如果上游返回的是弱ETag（形如W/"abc123"），Nginx会原样转发，但弱ETag在RFC7232中不能用于If-Range等场景，客户端行为可能与你预期不同。第二，Nginx自身可能成为验证方：当配置了proxy_cache后，Nginx会在缓存未过期时直接回复客户端，在过期后代替客户端向上游发起条件请求。这时HPACK登场了——Nginx向上游发送的If-None-Match正是通过HPACK编码传输的，动态表命中时只传一个索引号。
一个典型的坑是上游返回304响应时的头部处理。304在RFC7232中允许省略大部分实体头部，只带验证相关字段。上游通过HTTP/2回源时，304的头部经过HPACK压缩后可能非常小，但如果上游在304中省略了Cache-Control，而客户端缓存的原始响应里有这个头部，Nginx默认行为下客户端会沿用旧值，这符合规范，却经常被误判为“缓存指令丢失”。排查时要分清楚：这是RFC7232允许的语义合并，不是HPACK解码问题。
三、Nginx回源配置实践与日志排查方法
先看一份典型的回源HTTP/2配置。注意proxy_http2要求Nginx 1.9.5以上版本，且上游必须配置成HTTPS端点，因为HTTP/2协商依赖TLS的ALPN扩展：
upstream backend {
server 10.0.0.10:443;
keepalive 32; # 复用回源连接，动态表得以延续
}
server {
listen 443 ssl http2;
server_name www.ipipp.com;
location /api/ {
proxy_pass https://backend;
proxy_http2 on; # 回源启用 HTTP/2
proxy_ssl_server_name on; # SNI 必须开启，否则握手失败
proxy_set_header Host www.ipipp.com;
# 保留验证相关头部，明确转发给客户端
proxy_pass_header ETag;
proxy_pass_header Last-Modified;
# 条件请求透传：客户端的验证条件要传到上游
proxy_set_header If-None-Match $http_if_none_match;
proxy_set_header If-Modified-Since $http_if_modified_since;
proxy_cache mycache;
proxy_cache_revalidate on; # 过期后用条件请求向上游验证
proxy_cache_use_stale error timeout updating;
}
}
配置中有三处与本文主题直接相关。keepalive 32让回源连接保持长连，HPACK动态表在这些连接上累积，重复的头部如Host、User-Agent模板、公共Cookie都能被索引化，减少回源带宽。但要注意：如果上游关闭了连接（比如空闲超时），新连接的动态表从零开始，第一个请求的头部开销会明显变大，监控上表现为回源流量的锯齿状波动，这是正常现象而非故障。
日志排查方面，Nginx原生日志看不到HPACK层的东西，需要组合多层证据。第一层是状态码分布：在log_format中加入$upstream_http_etag和$upstream_status，对比上游返回304的比例与客户端收到304的比例是否一致：
log_format hpack_check '$remote_addr [$time_local] "$request" '
'status=$status upstream=$upstream_status '
'etag=$upstream_http_etag cc=$upstream_http_cache_control '
'cache=$upstream_cache_status';
access_log /var/log/nginx/hpack.log hpack_check;
第二层是抓包验证。用tcpdump配合nghttp或者Wireshark的HTTP/2解析器，可以直接看到DISCONNECT之前HEADERS帧里的HPACK编码形式：完全命中的头部只占一个字节的索引号，新增条目会看到动态表大小更新的信号。如果怀疑解码异常，可以临时把回源改回HTTP/1.1（proxy_http2 off）做对照测试——问题消失则说明焦点在HTTP/2链路，问题依旧则大概率是缓存配置或头部改写逻辑的问题。这种二分法在定位协议层疑难时非常有效。
四、常见误区与最佳实践总结
第一个误区是把gzip和HPACK混为一谈。gzip压缩的是响应体，HPACK压缩的是HTTP/2的头部字段，两者互不影响。但如果上游对同一个资源在不同请求参数下返回不同Content-Encoding，同时Vary头设置不当，缓存验证就可能串版本：客户端拿着资源A的ETag去验证资源B，得到看似矛盾的200响应。这时RFC7232没有失效，是缓存键设计的问题。
第二个误区是忽略Nginx自身的验证角色。配置了proxy_cache_revalidate on后，Nginx发给上游的条件请求头部同样经过HPACK编码。如果回源连接是新建的，动态表为空，If-None-Match会以字面量形式完整发送，没有任何问题；HPACK的正确性不依赖表是否命中，只依赖两端状态一致。所以不要因为“动态表为空”而怀疑验证头丢失。
总结成几条实践建议：回源启用HTTP/2时保持ALPN、SNI配置完整；用proxy_pass_header显式声明需要透传的验证字段，避免隐式行为带来的不确定性；在日志格式中固定记录上游ETag与缓存状态，为后续排障留下证据链；抓包时优先使用Wireshark的HTTP/2解码器查看HEADERS帧的编码细节；怀疑协议层问题时，用HTTP/1.1回源做对照是成本最低的定位手段。理解了HPACK动态表只是传输层优化、RFC7232的语义在解码后完整保留这一基本原则，绝大多数“缓存验证异常”都能被正确归因，而不是冤枉到压缩算法头上。