关键不是看“有没有长连接”，而是对比启用前后tcp建立次数、首字节时间（ttfb）、并发连接数增长曲线三项指标：开启keepalive后，1000次请求syn减少约80%，ttfb降低15–25ms，后端estab连接数更平稳，nginx cpu下降10–20%。
直接测连接复用带来的加速效果，关键不是看“有没有长连接”，而是对比启用前后在真实请求链路中的延迟变化和资源开销。重点观察 TCP 建立次数、首字节时间（TTFB）、并发连接数增长曲线这三项指标。
一、确认长连接已实际生效
先验证配置是否真正起作用，避免“配了但没生效”：
-
检查 Nginx 配置是否完整：确保同时设置了
proxy_http_version 1.1和proxy_set_header Connection ""，否则后端可能仍按 HTTP/1.0 处理，主动断连； -
抓包验证连接复用：用
tcpdump -i any port 8080 -w backend.pcap抓后端端口流量，在连续发起多个请求（如 10 次 curl）时，观察 TCP 握手（SYN）是否只出现 1 次，后续请求复用同一连接； -
查 Nginx 连接池状态：启用
stub_status模块后访问/nginx_status，关注Active connections和Reading/Writing/Waiting中的 Waiting 数量——长连接多时，Waiting 应明显高于 Reading+Writing。
二、设计可比性压测方案
用相同客户端、相同路径、相同 QPS，分别测试开启/关闭 keepalive 的两组配置：
-
关闭 keepalive 对照组：upstream 中删掉
keepalive指令，并设proxy_http_version 1.0； -
开启 keepalive 实验组：配置
keepalive 32+proxy_http_version 1.1+least_conn； -
压测工具建议：用
wrk -t4 -c100 -d30s http://your-domain/api/test，其中-c100模拟 100 并发连接，能稳定触发复用行为； -
必须采集的指标：平均延迟（Latency）、延迟 P95、每秒新建 TCP 连接数（可用
ss -s | grep "TCP:"定期采样）、后端服务的 ESTAB 连接数（ss -tan state established | wc -l）。
三、分析加速效果的核心证据
真正的加速体现在系统级开销下降，而非单次请求快了几毫秒：
- TCP 握手减少量：比如 1000 次请求，关闭 keepalive 产生约 1000 次 SYN；开启后若复用率 80%，仅新增约 200 次，节省 80% 握手开销；
- TTFB 下降幅度：实测中，HTTP/1.1 + keepalive 在微服务调用链（Nginx → API网关 → 用户服务）中，TTFB 通常降低 15–25ms，主要来自省去 SYN/SYN-ACK/RST 往返；
- 后端连接数更平稳：未启用时，连接数随请求洪峰剧烈波动（如 50→500→50），启用后维持在较窄区间（如 280–320），说明连接被有效复用；
- CPU 使用率下降：在同等 QPS 下，Nginx worker 进程 CPU 占用通常下降 10–20%，尤其在小包高频请求场景（如心跳、鉴权接口）中更明显。
四、微服务链路中需特别注意的干扰项
避免把其他环节的抖动误判为 keepalive 效果：
-
后端服务自身连接池：如果 Spring Boot 的 Tomcat 或 Netty 客户端没配好连接池，Nginx 的 keepalive 无法传递收益，需同步检查后端
maxConnections、keepAliveTimeout等参数； - 客户端行为影响：浏览器默认复用连接，但 Postman 或某些脚本工具可能每次新建连接，压测时务必用支持连接复用的工具（如 wrk、hey、或 Python 的 requests.Session）；
-
健康检查干扰：Nginx 默认的
health_check会定期建连，若间隔太短（如 1s），会掩盖复用效果，建议临时关闭或调大间隔再测试。
