least_conn在连接突增时能否毫秒级感知并导向最空闲后端是验证关键：需通过快慢节点压测、实时监控连接分布偏移速度、新请求落点切换延迟及错误信号，并配置max_fails、keepalive和禁用冲突策略，再与轮询对比验证效果。
测试 least_conn 在连接数突增时的响应，关键不是看它“能不能分发”，而是验证它能否在毫秒级内感知节点连接变化，并把新连接真实导向此刻最空闲的后端——尤其当某台机器因突发请求快速堆积连接时，算法是否及时绕开，避免雪崩式排队。
准备可触发突变的压测场景
必须让连接数在短时间内剧烈波动，才能暴露 least_conn 的响应灵敏度：
- 用两台后端，一台设为“稳定快节点”（sleep 50ms），另一台设为“突增慢节点”（前 10 秒正常，第 11 秒起模拟卡顿：sleep 2000ms 持续 30 秒）
- 压测客户端用 wrk 启动长连接：-t4 -c1000 -d60s --latency，确保连接复用，让活跃连接数持续累积而非瞬时归零
- 在第 10 秒末手动触发慢节点延迟，制造连接数突增拐点；同时开启实时监控，每 2 秒采集一次数据
重点观测三类实时指标变化
不能只看平均值，要抓突变窗口内的秒级行为：
-
连接分布偏移速度：从慢节点开始堆积起，观察另一台快节点的
Active connections（通过 stub_status 或 /nginx_status）是否在 3–5 秒内明显上升——说明 least_conn 已识别“此处更空闲”并开始导流 - 新请求落点切换延迟：解析 Nginx access_log，统计突变后 10 秒内新请求中落到快节点的比例。若 5 秒内该比例从 50% 升至 ≥85%，说明调度响应合格；若仍长期停留在 50% 附近，可能是 keepalive 连接未释放或 max_conns 未生效
-
错误与重试信号：检查 error.log 是否出现
upstream timed out或no live upstreams。若慢节点堆积过快但健康检查未剔除，least_conn 会继续尝试转发，直到超时触发重试——此时 proxy_next_upstream 配置是否生效，直接决定突增是否演变为级联失败
验证配置是否真正支撑快速响应
很多“响应慢”其实是配置拖了后腿，不是算法本身问题：
- 确认每个 server 行都带
max_fails=2 fail_timeout=10s：被动健康检查必须足够激进，才能在慢节点连接堆积初期就标记为不可用，辅助 least_conn 做出更准判断 - 检查
keepalive值是否合理：设为 32 是常见起点，但若后端连接池较小（如 Tomcat maxKeepAliveRequests=100），keepalive 过大会导致空闲连接长期占位，掩盖真实负载；建议保持 Nginx keepalive ≤ 后端单实例最大空闲连接数 × 0.7 - 确认没有启用
ip_hash或其他冲突策略：least_conn 必须是 upstream 块首行唯一算法指令，否则整个逻辑被忽略
对比轮询作基线，看差异是否显著
在同一压测条件下，把 upstream 改为 round-robin 再跑一遍：
- 记录慢节点连接数从 100 增至 800 所用时间（突增斜率）
- 对比 least_conn 下，快节点连接数是否同步上升、慢节点是否在达到 max_conns 后被跳过（需提前配好
max_conns=600） - 若轮询下慢节点连接数冲到 1200 且 P95 延迟翻倍，而 least_conn 下其连接数被稳在 600、整体延迟仅微升，则说明突增响应有效
