横向扩展中长连接有效性取决于多节点高并发下是否降低建连开销、稳定上游、避免连接池耗尽；需分三层测试：客户端-nginx复用、nginx-upstream连接池效率、多nginx节点行为一致性。
直接测长连接在横向扩展中的表现，关键不是看单台 Nginx 能不能复用连接，而是看它在多节点、多后端、高并发下，是否真能减少建连开销、压稳上游、避免连接池耗尽。测试要分三层：客户端到 Nginx、Nginx 到 upstream、以及多 Nginx 节点协同时的连接行为一致性。
一、验证客户端与 Nginx 的长连接复用
用 ab 或 wrk 发起带 Keep-Alive 的压测，重点观察 Nginx 的 stub_status 输出：
- 运行
curl http://localhost/stub_status，关注 Waiting 值 —— 它 = Active − (Reading + Writing)，持续稳定在 Active 的 80% 以上，说明客户端连接大量处于空闲复用状态 - 对比开启/关闭
keepalive_timeout 75s后的 accepts 与 handled 差值：差值明显变小，说明连接被复用，而非频繁新建/销毁 - 加参数
-H "Connection: keep-alive"显式声明（尤其用 curl/wrk 时），避免工具默认发 HTTP/1.0 请求导致连接无法复用
二、验证 Nginx 到 upstream 的连接池效率
这是横向扩展中最容易被忽略的一环：后端节点越多，连接池管理越关键。需结合配置与日志交叉判断：
- 在
upstream块中设keepalive 32，并确保proxy_http_version 1.1和proxy_set_header Connection ""已启用 - 开启 error.log 的 warn 级别，高频出现 "upstream connection is busy" 或 "no live upstreams"，说明连接池已满，要么调大
keepalive，要么后端响应变慢拖住连接 - 用
log_format记录$upstream_connect_time：若该字段大量为 "-" 或突增，代表 Nginx 正在反复建连，长连接失效
三、模拟集群横向扩展下的连接行为一致性
单台 Nginx 测试通过后，必须放到多节点场景中验证行为是否可预期：
- 部署至少两台 Nginx（如用 Docker Compose 启动），前端用 Keepalived 漂移 VIP，或用 DNS 轮询指向多个 Nginx IP
- 用同一组客户端（如固定 IP 的 wrk 实例）持续压测，观察各 Nginx 的 stub_status 中 Waiting 分布是否均衡 —— 若某台 Waiting 长期接近 0，而另一台极高，说明负载不均，可能因 least_conn 未生效或健康检查异常
- 主动 kill 一台 Nginx，观察剩余节点的 Active connections 是否陡增、Waiting 是否短暂归零后快速回升 —— 健康恢复快，说明连接复用机制未受故障转移影响
不复杂但容易忽略：横向扩展时，长连接的价值不在单点性能提升，而在降低整个集群的 TCP 连接总量和后端压力。真正有效的测试，是让 QPS 上去、连接数下来、error.log 安静下来。
