Nginx 反向代理开启 HTTP/2 回源后，偶尔会出现一批 502 请求，而客户端侧看到的往往是连接被重置或个别接口随机失败。检查 error.log 时，如果看到 upstream sent invalid http2 table index 之类的报错，说明 HTTP/2 的头部压缩上下文已经发生了错位。这类问题与普通上游超时不同，重点不在 TCP 握手，而在 HPACK 动态表的解码过程。
一、日志现象：错误集中在响应头解析阶段
当 Nginx 作为反向代理使用 HTTP/2 协议回源上游服务时，客户端请求通常走 HTTP/2 或 HTTP/1.1，Nginx 与上游之间则通过 proxy_http_version 2.0 建立 HTTP/2 连接。故障发生时，Nginx 的 error.log 不会记录 TCP 握手失败，而是给出非常具体的头部解码错误。典型日志片段如下：
2025/02/11 10:30:12 [error] 22134#0: *7781 upstream sent invalid http2 table index while reading response header from upstream, client: 203.0.113.10, server: api.ippipp.com, request: "GET /v1/orders HTTP/2.0", upstream: "http2://10.10.20.5:9443/v1/orders", host: "api.ippipp.com"
这里的 invalid http2 table index 表示上游返回的 HPACK 头部块中引用了一个动态表索引，但 Nginx 本地维护的动态表中并不存在该索引对应的条目。HTTP/2 协议将这类错误归为连接级错误，接收端不能只忽略当前流，而必须发送 RST_STREAM 帧并关闭整个 HTTP/2 连接。因此故障表现为一个 HTTP/2 连接上的多个请求同时失败，客户端通常会看到 502 Bad Gateway，或者连接被重置。
还有一部分日志可能显示 upstream sent invalid header block 或 header block is not allowed，这些都指向同一个问题：HPACK 上下文不一致。要注意的是，如果日志中混有 upstream prematurely closed connection while reading response header，则可能是动态表错误导致连接被对端提前关闭，而不是独立的网络故障。
二、HPACK 动态表为何会越界
HTTP/2 使用 HPACK 压缩头部，目的是减少重复字段带来的带宽浪费。HPACK 由一张静态表和一张动态表组成。静态表包含常见字段，例如 :method、:path、content-type 等，索引固定；动态表则由编码端在连接存续期间逐步填充，接收端根据同样的规则同步更新。动态表索引从 62 开始，编码端可以引用索引 62、63、64 等来代表之前已经发送过的完整头部键值对。
动态表能够正常工作有一个前提：编码端和解码端必须保持完全一致的动态表状态。RFC 7541 规定，两端通过 SETTINGS_HEADER_TABLE_SIZE 协商动态表最大容量，编码端只有在确认接收端能够容纳的情况下才能添加新条目。同时，当动态表满时，最旧的条目会被淘汰，所有后续索引都会前移。如果发送端和接收端对淘汰时机、索引变化的处理出现细微差异，就会出现索引错位。比如上游服务认为某个字段还在动态表索引 75 的位置，但 Nginx 已经按照自己的规则将索引 75 淘汰或指向了另一个字段，此时 Nginx 就会报 invalid http2 table index。
实际生产环境中，导致这种错位的原因通常有以下几类：上游 HTTP/2 实现没有严格按照 RFC 7541 更新动态表；Nginx 旧版本在处理上游 HTTP/2 连接复用时有逻辑缺陷；上游服务在滚动发布或连接复用期间没有正确重建动态表；某些 HTTP/2 客户端库在流并发场景下错误共享了动态表状态。需要明确的是，这个问题不是 Nginx 单方面的配置错误，而是双边状态同步失败，修复思路也要从 Nginx 与上游两端同时考虑。
三、定位：从配置、抓包和上游握手入手
首先检查 Nginx 的编译参数和回源配置。执行 nginx -V 确认是否包含 --with-http_v2_module，这是支持 HTTP/2 回源的基础。随后查看 proxy_http_version 是否设置为 2.0，以及上游是否真正支持 HTTP/2。如果上游是 HTTPS 服务，Nginx 会通过 ALPN 协商协议，必须在 TLS 握手阶段协商出 h2；如果上游只提供明文 h2c，则需要确认 Nginx 版本是否支持明文 HTTP/2 回源，并且上游监听是否真正启用了 h2c。
抓包是确认 HPACK 动态表问题最直接的手段。可以在 Nginx 所在机器上执行以下命令，抓取与上游之间的流量：
tcpdump -i eth0 -s 0 -w h2_upstream.pcap host 10.10.20.5 and port 9443
使用 Wireshark 打开抓包文件后，过滤 http2.type == 3 可以查看 RST_STREAM 帧，过滤 http2.header.name 可以展开 HEADERS 帧中的头部块。重点关注出现错误的流 ID，查看该 HEADERS 帧中引用的动态表索引是否超出了连接早期协商的容量。正常的 HTTP/2 通信中，动态表索引应该单调递增且引用连续，如果突然出现一个孤立的大索引，就说明上游编码端出现了状态错位。
此外，可以绕开 Nginx 直接验证上游服务的 HTTP/2 行为。使用 nghttp -nv https://upstream:9443/v1/orders 或 curl --http2-prior-knowledge 访问上游，观察是否复现头部压缩错误。如果上游自身就返回 compression error 或连接被重置，说明问题不在 Nginx，而在上游 HTTP/2 实现本身。此时应优先检查上游服务的 HTTP/2 库版本和配置，尤其是与 HPACK 动态表容量相关的参数。
四、修复与验证：按场景选择方案
如果确认问题来自 Nginx 对上游 HTTP/2 连接的处理缺陷，首选方案是升级 Nginx 主线版本。较新的稳定主线版本对 HTTP/2 上游连接的 RST_STREAM 处理、HPACK 动态表同步以及连接复用逻辑都有明显改进。升级后重新编译时务必保留 --with-http_v2_module，并平滑重载配置。典型的回源配置如下：
upstream backend_h2 {
server 10.10.20.5:9443;
keepalive 32;
}
server {
listen 443 ssl http2;
server_name api.ippipp.com;
location /api/ {
proxy_pass https://backend_h2;
proxy_http_version 2.0;
proxy_set_header Connection "";
proxy_set_header Host $host;
proxy_ssl_server_name on;
proxy_ssl_session_reuse on;
}
}如果业务对 HTTP/2 多路复用的依赖不强，或者上游 HTTP/2 实现短期内无法修复，最稳妥的方案是临时回退到 HTTP/1.1 回源。只需将 proxy_http_version 改为 1.1，同时保留 proxy_set_header Connection "" 以启用上游 keepalive 连接复用。这样 HPACK 动态表问题会彻底消失，代价是失去单连接多路复用，高并发下可能需要更多上游连接数。配置变更如下：
location /api/ {
proxy_pass https://backend_h2;
proxy_http_version 1.1;
proxy_set_header Connection "";
proxy_set_header Host $host;
proxy_ssl_server_name on;
}如果上游服务是自研或可配置的，可以尝试限制 HPACK 动态表容量。以 Go 的 golang.org/x/net/http2 为例，可以在服务端将动态表容量调小，或者直接禁用动态表，让所有头部都走静态表和字面量编码。这样虽然头部压缩率下降，但能从根本上避免索引越界问题。具体参数需要查看所用 HTTP/2 库的文档，通常与 MaxDecoderHeaderTableSize 或类似的选项有关。若上游无法修改，还可以通过调整 Nginx 与上游的连接复用策略来降低出错概率，例如适当减小 keepalive 连接池大小，使连接更频繁地新建，从而减少动态表长时间运行带来的错位风险。
修复完成后，使用压测工具验证效果。例如：
wrk -t4 -c100 -d60s https://api.ippipp.com/v1/orders
同时观察错误日志中是否还有新增的 invalid http2 table index 记录。如果之前的错误是按批次偶发，建议持续观察 30 分钟以上，并统计上游连接数变化。通过 ss -tan | grep 9443 确认 HTTP/2 上游连接能够稳定复用，而不是频繁断开重建。只有错误率降为零且连接行为符合预期，才能说明 HPACK 动态表修复生效。