直接用高延迟后端压测可验证least_conn真实调度逻辑：它只依据当前活跃连接数分发，不看响应快慢；测试需部署快慢节点（如sleep 100ms/800ms）、启用least_conn+keepalive+max_conns+健康检查，并用wrk长连接压测，通过stub_status观察连接是否自动绕开卡住节点。
直接用高延迟后端压测，就能看清 least_conn 在真实压力下的调度逻辑。它不看响应快慢，只数“当前还连着几个没关”，所以测试关键不是等结果快，而是盯住连接是否被有效绕开卡住的节点。
准备可控制延迟的后端服务
部署至少两台后端，每台提供一个 HTTP 接口，并人为制造差异延迟：
- 一台设为 sleep 100ms（快节点），另一台设为 sleep 800ms（慢节点）
- 关闭后端缓存和异步逻辑，确保延迟稳定可复现
- 启用 HTTP/1.1 + keepalive，禁用 linger 或设为 0，避免连接假性滞留
- 确保后端不主动快速断连，否则 Nginx 统计的活跃连接数会失真
配置 upstream 并开启可观测能力
在 Nginx 的 upstream 块中明确启用 least_conn，并配好配套机制：
- 写入 least_conn 和 keepalive 16–32（避免空闲连接虚高账面数字）
- 加上 max_conns 限制，例如快节点设 2000、慢节点设 800，让容量差异参与调度
- 启用主动健康检查：health_check interval=3 fails=2 passes=2，防止慢节点长期“活着却卡死”
- 开启 stub_status 模块，通过 /nginx_status 实时查看各后端的 active connections
用 wrk 做分阶段长连接压测
不用 ab 这类短连接工具，改用 wrk 模拟真实用户持续建立长轮询连接：
- 发起 1000+ 并发，每个连接保持直到后端返回（即真正长连接）
- 先稳压 30 秒观察 baseline，再阶梯加压（如每 30 秒 +500 RPS），直到 P95 延迟明显上扬
- 压测中持续采集：各后端的活跃连接数、$upstream_connect_time、$upstream_response_time
- 对比 round-robin 下的连接分布——least_conn 应该让慢节点连接数明显低于快节点
验证 least_conn 是否真起作用
不能只看平均响应时间，要交叉看三组数据：
- stub_status 中各 server 的 Active connections 是否呈现“快节点略高、慢节点被跳过”的趋势
- 当慢节点连接数持续接近 max_conns 时，新请求是否自动转向快节点
- 如果某节点连接数长期低但响应时间飙升，说明它可能卡在 GC 或 I/O，需结合后端监控定位
- 错误率突增且集中在某台后端？检查 health_check 是否生效，或 proxy_next_upstream 是否包含 timeout
