Nginx 反向代理回源时如果启用了 HTTP/2，会在与上游服务器的连接上启用 HPACK 头部压缩。请求头在发送前需要经过 HPACK 编码器，编码器会先查找静态表和动态表，找到匹配项时直接发送索引号，找不到才发送字面表示。动态表查找是否命中，直接影响回源请求的头部编码效率，也会影响后续动态表的更新和淘汰。排查此类问题时，不能只看访问日志，debug 日志中的 HTTP/2 细节和实际帧交互更关键。
HTTP/2 HPACK动态表在Nginx回源中的角色
HTTP/2 使用 HPACK 压缩头字段，静态表包含 61 个常见头域，索引从 1 到 61。动态表初始为空，随着通信进行，编码器和解码器通过头部块更新。Nginx 作为客户端回源时，会为每条请求构造 HEADERS 帧，编码请求头时先查静态表，再查动态表。动态表条目索引从 62 开始，因为前 61 个索引已预留给静态表。
动态表查找的核心逻辑是名称匹配和名称加值匹配。如果只需要发送索引号，说明一个头域完全匹配某个动态表条目；如果只有名称匹配而值不同，可以发送带有名称索引的字面表示。查找过程涉及遍历动态表条目，Nginx 内部使用 ngx_http_v2_get_indexed_header 之类的函数完成这一操作。动态表越大，查找耗时越长，尤其当回源请求携带大量自定义头或长尾头域时，头部编码阶段的 CPU 消耗会明显上升。
在回源场景中，Nginx 既可能是服务端接收客户端 HTTP/2 请求，也可能作为客户端向上游发起 HTTP/2 回源请求。前者会解码客户端头部，后者会编码上游请求头部。动态表查找主要体现在客户端侧编码阶段，也就是 Nginx 连接上游时的发送过程。理解这个方向，才能把日志里看到的索引号和动态表大小对应起来。
如何从Nginx日志中观察HPACK动态表查找
Nginx 的 access_log 默认只记录请求方法、状态码、耗时等，不会输出 HPACK 内部过程。要观察动态表查找，需要开启 debug 级别错误日志。可以在主配置或特定 location 中增加 error_log 指令，并通过 debug_connection 限定来源，避免日志过大。
error_log /var/log/nginx/http2-debug.log debug;
events {
debug_connection 127.0.0.1;
}
开启 debug 日志后，HTTP/2 模块会打印头部编码信息，通常包括头名称、头值、命中的索引、动态表当前大小等。当看到类似 http2 header index 或 http2 encode header 的记录时，可以根据索引值判断是否命中动态表。索引大于 61 一般表示动态表命中；索引为 0 或未显示索引，通常意味着字面表示，需要进一步确认是否后续插入动态表。
仅靠 Nginx 日志有时无法完整还原动态表查找，因为 debug 日志的详细程度受模块实现影响，某些版本只输出最终编码结果而不输出中间查找过程。此时可以配合抓包，使用 Wireshark 或 nghttp2 工具查看 HEADERS 帧中的索引字段，验证日志推断。抓包时重点看 SETTINGS_HEADER_TABLE_SIZE 和 HEADERS 中的 Indexed Header Field、Literal Header Field with Incremental Indexing 等标记。
动态表查找的性能影响与配置调整
动态表查找的代价主要来自线性遍历。当动态表容量达到几百项时，每次发送头部都要逐项比较名称和值，频繁回源且头部数量多时，CPU 开销会累积。Nginx 的 HTTP/2 模块对动态表查找做了基本优化，但无法改变 HPACK 算法本身的复杂度。因此减少不必要的变化头部、保持头顺序稳定，是提高动态表命中率的有效方式。
在实际配置中，回源启用 HTTP/2 通常使用 proxy_http_version 2.0。上游响应头也会进入 Nginx 的 HPACK 解码器，动态表更新可能影响后续请求的编码。可以观察上游是否频繁变化 set-cookie 或 etag 等值，这类头域很难命中动态表，却可能触发动态表插入和淘汰。通过 proxy_set_header 固定发送的自定义头，并使用简短稳定的值，有助于提升查找命中率。
location /api/ {
proxy_pass https://upstream.ipipp.com;
proxy_http_version 2.0;
proxy_set_header X-Trace-ID $request_id;
proxy_set_header Accept-Encoding "gzip";
}
这里用 $request_id 会使每个请求的值不同，该头域无法命中动态表，只适合少量必要场景。若头部值频繁变化，可考虑放到消息体或使用 gRPC metadata 等更合适的信道。动态表大小由上游在 SETTINGS 帧中声明，Nginx 作为客户端会遵守该限制，因此调整动态表容量通常需要修改上游服务器的 HTTP/2 参数，而不是只改 Nginx。
在排查性能问题时，可以对比关闭 HTTP/2 回源与开启 HTTP/2 回源的请求耗时。若发现开启后头部处理时间显著增加，且 debug 日志显示大量未命中的动态表查找，说明头部设计有问题。此时优化头部比单纯调大动态表更有效。
典型异常与定位流程
一种常见异常是上游返回 HTTP/2 stream error 或 Nginx 日志出现 header index out of range。这可能意味着编码器和解码器对动态表状态的理解不一致，例如动态表条目被淘汰后，索引号仍然被发送。Nginx 会记录相关错误并关闭对应的流或连接。此时需要结合上游 HTTP/2 实现版本、动态表大小设置以及请求头变化模式来排查。
定位流程可以按以下顺序进行：先开启 Nginx debug 日志，确认错误发生在编码阶段还是解码阶段；再用 nghttp -v 或 curl --http2-prior-knowledge -Iv 直接连接上游，观察头部压缩是否稳定；最后抓取 TCP 包，过滤 HTTP/2 帧，检查 HEADERS 帧中引用的动态表索引是否超过当前表大小。这能帮助判断问题来自 Nginx 还是上游实现。
nghttp -vn https://upstream.ipipp.com/health curl --http2-prior-knowledge -Iv https://upstream.ipipp.com/health
总结来说，Nginx 回源 HTTP/2 的 HPACK 动态表查找虽然不直接体现为日志中的一个字段，但通过 debug 日志、抓包和配置调整，可以定位头部压缩相关的大部分问题。优化重点是稳定头部、减少长尾字段，并配合上游协商合适的动态表大小。