least_conn的稳定性测试需验证其在高并发、响应不均、连接堆积下能否准确导向空闲节点：通过快慢后端（sleep 100ms/800ms）、可控keepalive、固定响应体构建真实环境，结合stub_status与conn-stats观测连接分布，用wrk长连接压测并分阶段分析调度行为。
测试 least_conn 的稳定性与健壮性，核心是验证它在高并发、响应不均、连接堆积等真实压力下，能否持续把新请求导向真正空闲的后端节点，而不是被假象误导或陷入调度失灵。
构造响应差异明显的后端环境
least_conn 不看响应快慢，只看连接数；但响应慢会直接导致连接堆积——这正是检验它是否“识数”的关键场景：
- 部署至少两台后端，分别模拟不同处理能力：一台 sleep 100ms（快节点），一台 sleep 800ms（慢节点）
- 关闭后端缓存与异步延迟干扰，确保响应时间可控、可复现
- 每台后端启用 HTTP/1.1 + keepalive，并禁用 linger 或设 linger=0，避免连接假性滞留
- 统一返回固定大小响应体（如 200 字节），排除网络传输波动对连接生命周期的影响
配置 Nginx 并开启可观测能力
算法生效的前提是配置到位且能被验证：
- upstream 块中明确写 least_conn; 和 keepalive 32;（数值按实际并发调整，建议 16–64）
- location 中设置 proxy_http_version 1.1; 和 proxy_set_header Connection '';，确保连接复用
- 编译时已启用 --with-http_stub_status_module，通过 /nginx_status 实时查看各 upstream server 的活跃连接数
- 后端机器上提供 /conn-stats 接口，用 ss -tn state established '( dport = :8080 )' | wc -l 统计 ESTABLISHED 连接数
用 wrk 做分阶段长连接压测
短连接工具（如 ab 默认模式）会让 least_conn 失效，必须用维持真实连接的方式驱动：
- 启动 wrk：wrk -t4 -c500 -d60s --latency -H "Connection: keep-alive" http://nginx-lb/api/long-poll
- 第一阶段：从 1000 RPS 起步，每 30 秒加 500 RPS，观察 P95 延迟拐点与错误率突增点
- 第二阶段：在瓶颈流量下稳压 2 分钟，同步采集 stub_status 输出、各后端 conn-stats、Nginx access_log 中 $upstream_addr 和 $connection_requests 字段
- 重点比对：慢节点连接数是否明显高于快节点？新请求是否在慢节点连接堆积后快速转向快节点？
识别健壮性失效的典型信号
连接分布不均不一定是 least_conn 失效，更可能是环境或配置干扰：
- 某节点连接数长期是其他节点的 2 倍以上 → 检查其 $upstream_response_time 是否显著偏高，确认是否因慢响应持续占位
- 所有节点连接数都趋近 max_conns 上限 → 可能 keepalive 设置过大，大量空闲连接占满“账面名额”，调小 keepalive 值再试
- stub_status 显示某节点 active conn 持续为 0，但 access_log 却有大量请求落到它 → 健康检查未生效（检查 max_fails / fail_timeout 配置）或后端主动断连过快
- 多网关集群中各节点调度结果不一致 → 确认所有 upstream 配置完全相同，且无 weight 或 backup 等隐含影响项
