排查回源链路问题时，多数人会先看Nginx的error.log和access.log，但如果回源走的是HTTP/2，问题往往会藏得更深。HTTP/2在单条TCP连接上多路复用请求，头部又经过HPACK压缩，一旦动态表状态在两端失步，Nginx的日志里可能只剩下一句含糊的 upstream prematurely closed connection，真正的原因却藏在协议层。这篇文章就把日志分析、HTTP/2回源配置、HPACK动态表机制这三个环节串起来讲清楚。
一、从Nginx日志入手：定位回源异常的第一现场
遇到回源失败，第一步永远是确认日志级别是否足够。Nginx默认的error级别日志会过滤掉大量有用信息，建议在排障阶段临时将日志级别降到info甚至debug（需要编译时带--with-debug）。观察下面这段配置：
error_log /var/log/nginx/error.log debug;
log_format upstream_detail '$remote_addr [$time_local] "$request" '
'upstream=$upstream_addr status=$status '
'upstream_status=$upstream_status '
'upstream_connect_time=$upstream_connect_time '
'upstream_header_time=$upstream_header_time '
'upstream_response_time=$upstream_response_time '
'upstream_bytes_received=$upstream_bytes_received';
access_log /var/log/nginx/access.log upstream_detail;
这几个内置变量是排障的核心。$upstream_connect_time偏高说明TCP或TLS握手慢，$upstream_header_time异常往往是上游处理慢或HTTP/2流被阻塞，而$upstream_status返回000则意味着连接根本没有建立完整响应，常见于HTTP/2回源时上游主动断开连接。
需要特别注意的是，当Nginx作为客户端向上游发起HTTP/2请求时（例如通过proxy_http2 on配合gRPC或Upstream模块的新版本特性），错误日志中出现的stream 5, stream 7这类编号就是HTTP/2的流ID。如果多条日志显示不同流ID在同一条连接上同时报错，基本可以判定是连接级别的故障，而不是单个请求的问题。此时要重点关注HTTP/2的连接层参数配置，而不是反复检查业务代码。
二、HTTP/2回源与HPACK动态表的工作机制
HTTP/2用HPACK压缩头部，靠的是一张静态表加一张动态表。静态表是协议里预定义的61个常见头部与取值，动态表则是在连接生命周期内按FIFO原则维护的索引区，两端通过收发带有索引的头部块来复用已经出现过的键值对。HPACK的高效依赖一个前提：发送方和接收方的动态表状态必须严格同步。任何一侧的表状态错乱，后续所有引用索引的头部都无法正确解码，连接也就废了。
动态表的容量由SETTINGS帧中的SETTINGS_HEADER_TABLE_SIZE控制，默认4096字节。发送方可以通过动态表大小更新指令要求接收方调整上限。这里有一个很容易踩的坑：如果Nginx向上游通告了一个较大的动态表容量，而上游实现（尤其是一些老版本的服务端或中间代理）在处理更新指令时存在bug，两端对表大小的理解不一致，就会出现解码错误，表现为上游直接返回RST_STREAM或者干脆关闭整条连接。
另外，动态表存在容量上限，超出后旧的条目会被逐出。当Nginx转发大量带有不同Cookie、不同X-Forwarded-For取值的请求时，这些大体积头部不断进出动态表，索引命中率下降，压缩收益变差，还会加速表的抖动。极端情况下，如果某个头部超过动态表总容量，按照规范该条目不会被插入表中，但部分实现处理不当也会引发异常。排查时可以通过抓包观察HEADERS帧里是索引引用多还是字面量多，字面量占比过高通常说明动态表没能发挥作用。
三、配置调优与抓包验证
针对HTTP/2回源场景，Nginx侧有几个参数值得逐项核对。grpc_http2_max_concurrent_streams控制单条连接上的最大并发流，keepalive配合upstream块可以复用长连接，减少握手开销。示例配置如下：
upstream backend {
server 10.0.0.8:443;
keepalive 32;
keepalive_requests 1000;
keepalive_timeout 60s;
}
server {
listen 443 ssl http2;
location /api/ {
grpc_pass grpcs://backend;
grpc_socket_keepalive on;
grpc_read_timeout 30s;
}
}
抓包验证是确认HPACK问题的最直接手段。用tcpdump抓取回源流量，再交给Wireshark分析：
tcpdump -i eth0 -w http2_trace.pcap host 10.0.0.8 and port 443
在Wireshark中开启SSLKEYLOGFILE解密TLS流量后，可以逐帧查看HEADERS块的解码结果。如果看到Wireshark提示HPACK解码错误或者大量Literal Header Field（不带头部索引的字面量），就要怀疑动态表状态问题。此时可以尝试在两端将表大小显式收敛到默认值，比如在Nginx的http2相关配置或对端服务中把头部表大小限制回4096，排除实现差异带来的兼容性问题。
关于规范本身，HPACK由RFC 7541定义，HTTP/2由RFC 7540定义，后来7540被RFC 9113取代。网络上流传的所谓RFC9990编号并不可靠，它不是HTTP/2或HPACK的正式规范文档，查阅协议细节时应以IETF官方发布的RFC 7541和RFC 9113为准，避免被错误资料误导。
四、一套可复用的排查流程
总结前面的内容，遇到Nginx回源异常时可以按四步走：第一步，降日志级别，抓取带upstream详情的access日志，确认故障是连接级还是请求级；第二步，核对HTTP/2回源配置，特别是keepalive、并发流上限和超时参数；第三步，tcpdump加Wireshark解密分析HEADERS帧，观察HPACK索引引用情况和是否存在RST_STREAM、GOAWAY帧；第四步，根据抓包结论调整两端动态表容量与连接复用策略，逐步收敛配置。
HTTP/2回源链路的故障往往不是单一配置造成的，而是连接复用策略、头部压缩状态和上游实现三者叠加的结果。把日志变量、协议机制和抓包工具都握在手里，遇到问题才不会只盯着500错误干瞪眼。建议在测试环境搭建一套可复现的回源链路，平时多抓几包熟悉HEADERS帧的形态，真正出问题时就能快速定位到协议层。