必须先验证HTTP/2真实协商成功，再监控连接复用、帧调度及响应时长等指标，结合curl、Chrome DevTools、tshark交叉确认；通过日志、stub_status、Prometheus采集h2专属QPS、平均响应时长、活跃连接数，并与HTTP/1.1对比；最终以WebPageTest压测和HPACK压缩率验证多路复用与头部压缩实效。
监控 Nginx 处理 HTTP/2 的请求效率与吞吐量，不能只看“是否启用了 http2”，而要聚焦协议真实生效后的连接行为、帧调度和业务级响应表现。核心是把协议能力转化为可观测指标，并与 HTTP/1.1 对比验证优势是否落地。
确认 HTTP/2 协议实际协商成功
协议未真正启用，后续所有监控都无意义。必须交叉验证 ALPN 协商结果：
- 用
curl -I --http2 https://your-site.com检查响应行是否为HTTP/2 200（不是HTTP/1.1 200） - Chrome DevTools → Network → 右键表头勾选 “Protocol”，确认资源请求显示
h2 - 抓包验证 TLS 握手：运行
tshark -i any port 443 -Y "tls.alpn" -T fields -e tls.alpn.protocol，输出应含h2
采集 HTTP/2 特有连接与帧层指标
效率瓶颈常藏在流控制和空闲连接管理中，需结合日志与系统状态定位：
- 启用专用日志格式记录协议类型：
log_format http2 '$time_local $uri $status $body_bytes_sent $http2 $request_time $upstream_response_time';
其中$http2值为h2表示走 HTTP/2，-表示降级或非 h2 - 监控
http2_idle_timeout（新版中由keepalive_timeout统一接管）是否过短：若大量连接在空闲几秒后被断开（tcpdump 见 FIN），说明复用率低，吞吐受重连拖累 - 检查 error.log 中是否频繁出现
stream ID is too large或client closed connection while waiting for request，提示http2_max_concurrent_streams或http2_max_requests设置不合理
从 stub_status 和 Prometheus 获取结构化吞吐与效率数据
原始文本指标需转化成可对比、可归因的吞吐与效率值：
- 通过
/nginx_status定期采样requests字段，计算单位时间增量 → 得到节点级 QPS；再结合Writing连接数，判断高吞吐是否伴随发送阻塞（如 Writing 长期 > 80% worker_connections） - 接入
nginx-vts-exporter后，关键指标包括：
—nginx_vts_server_requests_total{protocol="h2"}（HTTP/2 专属请求数）
—nginx_vts_server_request_seconds_sum{protocol="h2"} / nginx_vts_server_request_seconds_count{protocol="h2"}→ 平均响应时长
—nginx_vts_server_connections_total{state="active", protocol="h2"}（实时活跃 h2 连接） - 对比相同路径下
protocol="h2"与protocol="http1x"的request_seconds_sum / count，若 h2 响应时间未明显下降，需排查上游延迟或头部压缩失效
结合压测与页面级表现做闭环验证
最终要看用户感知——多路复用有没有减少等待，头部压缩有没有降低传输开销：
- 用 WebPageTest 或 Lighthouse 对比同一页面在 h2/h1 下的 TTFB、首屏完成时间、并发请求数；若并发请求数仍卡在 6 左右，说明多路复用未生效（可能被中间设备拦截 ALPN）
- 抓取两个协议下的请求头大小，HPACK 应使 header 字节减少 60%+；若差距微弱，检查
http2_max_header_size是否过小（JWT 等大 header 易触发帧拆分） - 观察
/nginx_status中Waiting占比：h2 场景下该值应显著高于 h1（因连接复用更久），但若Waiting高而 QPS 低，说明客户端复用不足或 CDN 缓存未命中
