在Nginx作为反向代理向上游服务器建立HTTP/2回源连接的场景中，头部压缩所使用的HPACK机制并不是每个请求独立从头开始的。HPACK动态表会在同一个HTTP/2连接上跨多个请求和响应持续存在，这意味着前一个响应的头部字段可能仍留在动态表中，并被后续请求引用。RFC9890对HPACK动态表在连接复用、表大小变更以及错误恢复方面的行为做了更明确的规范，直接影响了Nginx回源链路的稳定性。
HPACK动态表在Nginx回源中的基本工作方式
当Nginx通过proxy_http_version 2.0;指令向上游开启HTTP/2回源时，它与上游之间会协商建立一个HTTP/2连接。在这个连接上，所有请求和响应都复用同一个HPACK编码器与解码器状态。HPACK将频繁出现的头部如:authority、content-type等以索引形式放入动态表，后续传输只需发送索引号，从而显著降低头部开销。Nginx默认会按照RFC7541维护动态表，但在长连接和连接池复用情况下，动态表的生命周期往往超出单个逻辑事务。
理解这一点非常关键：如果上游在中间重置了HTTP/2流但没有告知Nginx动态表需要回滚，或者Nginx自身因配置变更缩小了SETTINGS_HEADER_TABLE_SIZE，而未按RFC9890的约束通知对端清理相关索引，就会出现两端动态表不一致。这种不一致在普通浏览器访问时较少暴露，因为浏览器与服务器通常是点对点短生命周期或严格遵循协商；但在Nginx回源这种多租户、长连接代理模型中，风险被放大。
下面是一段简化的Nginx回源配置示例，其中开启了HTTP/2并设置了头部表大小：
http {
upstream backend {
server 127.0.0.1:8080;
keepalive 32;
}
server {
listen 80;
location / {
proxy_pass https://backend;
proxy_http_version 2.0;
# 向上游声明更大的HPACK动态表上限
proxy_set_header SETTINGS_HEADER_TABLE_SIZE 4096;
}
}
}
RFC9890对动态表边界与重置的具体约束
RFC9890主要澄清了当HPACK动态表因设置变更或连接错误需要截断时，哪一方负责、以什么顺序回收索引。在旧的理解中，不少实现认为只要发送SETTINGS帧将表大小调小，对端就应该立即丢弃超出部分的条目；但RFC9890指出，发送方在收到对端确认前，仍可能按旧表大小编码，接收方也必须能容忍临时的表状态错位，直到ACK完成。Nginx若未实现该容忍逻辑，就可能在回源时因上游提前缩表而解码失败。
另一个重点是动态表与流关闭的关联。RFC9890明确，单个HTTP/2流的RST_STREAM不应导致整个连接的HPACK动态表回滚，除非连接级错误发生。某些早期Nginx补丁曾错误地在流重置后清空动态表，造成后续请求引用失效索引。在回源场景中，上游若频繁重置超时流（例如防护层限流），Nginx侧就会观察到大量HPACK_DECOMPRESSION_FAILED类错误，进而触发连接断开并重连，形成性能抖动。
我们可以通过对比表来看RFC9890前后常见实现的差异：
| 行为点 | RFC7541时代常见做法 | RFC9890要求 |
|---|---|---|
| 收到缩表SETTINGS | 立即丢弃超出条目 | 等待ACK，期间兼容旧索引 |
| 流RST_STREAM | 部分实现清动态表 | 仅连接错误才回滚 |
| 解码索引越界 | 直接断连 | 可发错误帧并恢复 |
未遵循RFC9890在Nginx回源中的实际故障与规避
在生产环境中，若Nginx版本较旧且上游已按RFC9890行为实现，最常见的现象是回源偶发502 Bad Gateway，错误日志中出现upstream sent frame for closed stream或invalid header index。这是因为上游在缩表后依旧引用了被Nginx误删的索引，或Nginx在流重置后误清表导致引用失效。此类问题在压力高峰、上游频繁调参时尤为明显，且难以通过单纯重试解决，因为新连接可能很快复现同样状态。
规避方案首先是升级Nginx至已合入RFC9890相关修复的分支（如主线较新版本或各发行版backport版本），并在nginx.conf中避免对回源连接频繁变更SETTINGS_HEADER_TABLE_SIZE。如果暂时无法升级，可通过关闭回源HTTP/2（退化为HTTP/1.1）或调小keepalive数量来缩短连接生命周期，降低动态表长期复用带来的状态偏差概率。以下代码展示了如何在无法升级时临时降级：
location / {
proxy_pass https://backend;
# 不使用HTTP/2回源，避开HPACK动态表问题
proxy_http_version 1.1;
proxy_set_header Connection "";
}
最后需要强调的是，监控层面应当采集Nginx的$upstream_response_time与错误码分布，并配合error.log中HPACK相关关键字做告警。只有将协议层规范与运维手段结合，才能在Nginx回源开启HTTP/2时真正发挥HPACK的压缩优势，而不是被RFC9890带来的边界差异拖垮稳定性。