最有效方式是直接压测对比：搭建客户端→nginx网关→微服务最小闭环，配置baseline版（无upstream keepalive）与keepalive版（upstream keepalive 32、http/1.1、connection头清空），用wrk压测/api/users路径，对比qps、p95/p99延迟、传输速率及后端established连接数，结合nginx连接日志验证$connection_requests是否>1和$upstream_connect_time是否仅首次出现。
直接压测对比是最有效的方式。关键不是“有没有长连接”，而是看它在真实微服务调用链路中是否真正复用、是否降低后端连接压力、是否提升端到端吞吐。
准备可比的两套环境
搭建一个最小闭环：客户端 → Nginx网关 → 微服务（如Spring Boot或Go服务），确保后端服务本身支持HTTP/1.1 Keep-Alive（例如Tomcat默认开启，Spring Boot内嵌Tomcat需确认server.connection-timeout > Nginx的proxy_read_timeout）。
配置两版Nginx：
-
Baseline版：不启用upstream keepalive，仅保留默认
proxy_http_version 1.0或未清Connection头 -
Keepalive版：在upstream块中加
keepalive 32，server中配proxy_http_version 1.1和proxy_set_header Connection ""
两个版本其余参数（超时、缓冲区、负载均衡算法等）必须完全一致，避免干扰项。
用 ab 或 wrk 做定向压测
不建议只测首页或静态资源，应模拟典型网关流量特征：带路径前缀、含简单Header（如X-Request-ID）、响应体大小适中（1–5 KB）。
示例命令（使用wrk更推荐，它原生支持HTTP/1.1长连接和连接复用）：
wrk -t4 -c100 -d30s --latency "http://nginx-gateway/api/users"
分别对两套Nginx配置运行3次，记录以下核心指标：
- Requests/sec（QPS）——看吞吐提升幅度
- Latency p95/p99——长连接对尾部延迟是否有改善
- Transfer/sec——确认响应体未被截断或压缩干扰
注意：ab默认使用HTTP/1.0，若强制测试Keep-Alive需加-H "Connection: keep-alive"并配合-k参数；但ab无法控制连接复用粒度，wrk或go-wrk更贴近真实场景。
观察后端连接状态变化
长连接的价值最终体现在后端。在微服务节点上执行：
ss -tan | grep :8080 | wc -l # 统计ESTABLISHED连接数
持续压测期间，对比两组Nginx下后端的活跃TCP连接数。理想情况下，Keepalive版应稳定在几十个连接（接近upstream keepalive值 × worker进程数），而Baseline版会随并发数线性飙升，甚至触发TIME_WAIT堆积。
同时检查后端日志中的连接建立频率（如Tomcat的org.apache.tomcat.util.net.NioEndpoint DEBUG日志），验证Nginx是否真正在复用连接而非频繁新建。
结合网关日志验证连接复用行为
在Nginx配置中临时开启连接级日志：
log_format conn '$remote_addr - $remote_user [$time_local] '
'"$request" $status $body_bytes_sent '
'conn:$connection reqs:$connection_requests '
'upstream_addr:$upstream_addr upstream_connect_time:$upstream_connect_time';
access_log /var/log/nginx/keepalive.log conn;
压测后分析日志，重点关注：
-
$connection_requests是否明显大于1（说明单连接处理了多个请求） -
$upstream_connect_time是否集中在首次请求，后续请求该值为“-”或极小（说明复用了已有连接） - 同一
$connectionID是否对应多个不同$request_uri（确认跨路径复用）
这能排除“看似开启实则未生效”的常见配置失误，比如忘记proxy_set_header Connection ""导致Nginx仍向后端发Connection: close。
