HTTP/2协议在带来多路复用和头部压缩收益的同时，也给排障带来了新的困惑：明明抓到了客户端请求，头部字段却是一串无法阅读的字节。不少人把这个现象误认为Nginx在“回源”时做了加密或者数据损坏，其实真正的原因是HTTP/2使用了HPACK头部压缩算法，其中包含的哈夫曼熵编码让头部字节流天然不具备可读性。要理解Nginx日志里看到的HTTP/2现象，必须先弄清HPACK的工作机制。
HPACK到底做了什么：静态表、动态表与哈夫曼编码
HPACK是RFC 7541定义的头部压缩算法，核心思想是“不再重复传输出现过的头部”。它由三部分组成：静态表、动态表和哈夫曼编码。静态表预置了61个最常见的头部键值对，例如索引为2的字段是method: GET，索引为8的是status: 200。客户端发送请求时，如果头部命中静态表，只需传输一个字节的索引值，而不用把整个字符串发出去。
动态表则是一个按连接维护的先进先出队列。同一条HTTP/2连接上，第一个请求会把user-agent、cookie等长字符串插入动态表并返回索引号，后续请求直接引用该索引即可。这就带来一个关键特性：HPACK的解码结果依赖于完整的会话上下文。如果你从中间某个数据包开始抓包，没有看到动态表的插入过程，就无法还原引用了动态表索引的头部内容。这也是Wireshark解析HTTP/2时常显示解码失败的根本原因，并非Nginx出了问题。
第三层是哈夫曼编码。HPACK规范内置了一张针对HTTP头部文本统计出的哈夫曼码表，字符串可以整体用哈夫曼编码传输以进一步压缩体积。经过哈夫曼编码的字节流在字节层面完全不可读，即便头部值本身很短（比如只压缩节省几个字节），规范也允许发送方选择是否使用。Nginx默认启用哈夫曼编码，所以抓包看到的头部字段是乱码属于正常现象。
Nginx中与HTTP/2和日志相关的处理流程
Nginx在ngx_http_v2_module中处理HTTP/2流量。收到HEADERS帧后，会经过HPACK解码还原出完整的头部字段，再进入标准的HTTP请求处理阶段。也就是说，到了access_log阶段，$http_user_agent、$http_cookie这些变量已经是解码后的明文，日志内容并不会受HPACK影响。如果你在日志里看到的是乱码，那问题多半出在客户端直接把未解码的原始字节写进了某个自定义头部，或者日志编码配置有误。
所谓“回源”场景中的HPACK问题，通常指的是Nginx作为正向或反向代理向后端转发请求。需要注意，Nginx与后端之间的连接默认是HTTP/1.1（除非使用gRPC模块或显式配置），所以即使客户端走HTTP/2进来，Nginx与上游之间不会复用HPACK动态表，后端收到的仍是明文头部。如果后端服务自己也启用了HTTP/2监听，可以在proxy_pass中使用https协议头并配置正确的SNI来走HTTP/2，但常规做法是保持内部HTTP/1.1，简化排查。
验证方式很简单：在server块中开启http2日志相关变量，观察$server_protocol的值。示例如下：
# nginx.conf 片段
log_format h2debug '$remote_addr - $server_protocol '
'"$request" $status $body_bytes_sent '
'ua=$http_user_agent';
server {
listen 443 ssl http2;
ssl_certificate /etc/nginx/certs/server.pem;
ssl_certificate_key /etc/nginx/certs/server.key;
access_log /var/log/nginx/h2_access.log h2debug;
location / {
proxy_pass http://127.0.0.1:8080;
}
}日志中$server_protocol显示HTTP/2.0就说明客户端确实在用HTTP/2，而$request和$http_user_agent正常可读，证明HPACK解码已在Nginx内部完成。
排查与抓包还原HPACK内容的实用方法
如果确实需要从抓包层面还原HTTP/2头部，核心原则是保证Wireshark拿到完整会话。第一，抓包必须从TCP/TLS握手开始，中间加入的连接无法补全动态表状态。第二，让Wireshark能够解密TLS层，可通过配置SSLKEYLOGFILE环境变量让客户端导出会话密钥，或在服务器侧使用sslkeylog相关补丁。解密成功后，Wireshark的HTTP/2解析器会自动重建动态表并完成哈夫曼解码，头部即可完整还原。
对于Nginx侧的排查，还可以利用$upstream_http_系列变量检查后端返回的头部，以及通过curl --http2 -v直接观察与Nginx协商的结果。若怀疑动态表状态被重置，可关注协议中的SETTINGS帧和HEADERS帧里是否携带了动态表尺寸更新标志，这类异常一般源于中间代理篡改或版本过旧的客户端实现，与Nginx本身的HPACK实现无关。
总结一下：HPACK的乱码不是故障，而是HTTP/2高效压缩的必然结果。日志层面Nginx早已帮你解码成明文；抓包层面则要保证密钥和完整连接上下文。理解这三层机制后，再遇到HTTP/2相关的“回源乱码”问题就能快速定位方向，不必在Nginx配置上盲目折腾。