在将Nginx配置为反向代理并向上游启用HTTP/2协议时，不少运维同学会在日志里观察到一种奇怪现象：明明后端服务没有重启，access日志中却周期性出现上游连接重建记录，且部分请求的回源耗时明显高于常态。进一步抓取报文会发现，HTTP/2连接的HPACK动态表处于不断变化的状态，旧条目被迅速清除，新条目反复写入。这种现象就是HPACK动态表驱逐，它并非Nginx缺陷，而是协议层与连接复用策略叠加后的必然结果。
HPACK动态表的基本工作原理
HTTP/2为了降低头部冗余，采用了HPACK头部压缩机制。HPACK维护两张表：静态表由协议规范固定，包含常见头部字段如:method、:path等；动态表则针对于当前连接，缓存本次连接中实际传输过的头部字段名与值。当客户端或代理发送请求时，若某头部已存在于动态表，只需发送一个索引号，不必重复传输原文。动态表的大小由SETTINGS帧中的SETTINGS_HEADER_TABLE_SIZE控制，默认通常为4096字节。
动态表采用先进先出的淘汰策略。一旦新条目加入导致表总大小超过上限，最早进入的条目就会被逐出，这就是所谓的驱逐。在浏览器与单台服务器长连接场景中，由于连接稳定且头部高度重复，动态表命中率很高。但在Nginx回源的场景里，连接并不总是由终端用户保持，而是Nginx主动与上游建立，其生命周期受代理配置与上游行为影响，这使得动态表的稳定性被打破。
需要明确的是，HPACK动态表是“每连接独立”的。不同TCP连接之间完全不共享动态表状态。因此每当Nginx因任何原因重新建立一条到上游的HTTP/2连接，该连接的动态表必然从空开始。从协议视角看，旧连接表的清空不算驱逐，但新连接反复从零积累条目的过程，在监控和日志层面就表现为动态表频繁初始化与快速增长，继而触发内部淘汰。
Nginx回源连接断裂如何引发表重建
Nginx通过proxy_http_version 2;指令开启回源HTTP/2。默认情况下，Nginx会根据上游响应及自身缓存的keepalive连接池来复用连接。然而在负载均衡、容器调度或上游主动断连时，连接会被回收。下面这段配置展示了基础回源设置：
upstream backend {
server 10.0.0.2:443;
keepalive 32;
}
server {
listen 443 ssl;
location / {
proxy_pass https://backend;
proxy_http_version 2;
proxy_set_header Host $host;
}
}
当keepalive池中的连接因proxy_timeout或上游GOAWAY帧被释放，下一次请求就必须发起新的TLS握手与HTTP/2连接 preface。此时HPACK动态表为空，前几个请求会完整发送头部，动态表逐渐填充。如果业务流量本身带有大量随机化头部，例如每次请求插入唯一追踪ID或带有随机值的x-request-token，动态表会迅速被这些一次性条目占满，导致真正可复用的公共头部被挤出。
此外，Nginx在检测到上游证书变更或配置 reload 时，会主动关闭旧连接。若系统频繁灰度发布，上游实例证书轮换，回源连接便会周期性重置。每一次重置都等价于动态表报废。在日志中，这体现为upstream_connect_time出现毛刺，以及$upstream_addr发生跳动，容易被误判为网络抖动而非HPACK行为。
通过参数调优降低驱逐频率的实践
要解决动态表频繁失效带来的隐性开销，核心思路是延长回源连接寿命并减少无谓头部。首先可以调大proxy_timeout与keepalive_timeout，让连接尽可能留在池中。同时适当提高HTTP/2接收超时，避免空闲连接被过早清理：
server {
listen 443 ssl;
http2_recv_timeout 60s;
location / {
proxy_pass https://backend;
proxy_http_version 2;
proxy_timeout 300s;
proxy_set_header Host $host;
# 避免写入随机头部到上游
proxy_set_header x-request-token "";
}
}
其次，应审视转发到上游的头部集合。很多应用为了排障会在Nginx侧追加x-forwarded-for、x-trace-id等，其中部分值高度随机。若上游并不需要这些字段参与压缩优化，可考虑在回源时移除或改为固定值，从而降低动态表污染速度。你也可以通过lua脚本在转发前清洗头部，但需注意这会增加CPU占用。
最后，在极端高并发且上游支持的情况下，可以启用Nginx的upstream连接池共享，并结合zone指令让多个worker共用keepalive状态，减少因进程隔离造成的连接碎片。如此一来，单条HTTP/2连接的存活率提升，HPACK动态表命中率随之提高，日志中的异常建链与延迟抖动会明显回落。理解并顺应HPACK的每连接特性，比盲目扩大表尺寸更有效。