验证Nginx least_conn策略需通过长连接压测与实时监控观察动态调度：初始均衡分配，节点下线后自动剔除并重分流量，上线后按活跃连接数渐进恢复流量。
要验证 Nginx 的 least_conn 负载均衡策略在后端节点动态上下线时是否真正生效，关键不是只看配置是否写对，而是通过可观察、可复现的操作+实时指标来确认其调度行为是否符合“当前活跃连接数最少”的逻辑。
一、准备带连接监控的测试环境
先确保 Nginx 启用了状态模块（如 ngx_http_stub_status_module）或使用第三方模块（如 nginx-module-vts），否则无法实时查看各 upstream server 的活跃连接数。推荐用 vts 模块，它能直接暴露每个 server 的 active 连接数、请求计数、失败次数等，配合 Prometheus + Grafana 可直观对比。
示例 upstream 配置：
upstream backend {least_conn;
server 127.0.0.1:8001 max_fails=1 fail_timeout=10s;
server 127.0.0.1:8002 max_fails=1 fail_timeout=10s;
server 127.0.0.1:8003 max_fails=1 fail_timeout=10s;
}
二、构造长连接压测并观察初始调度
least_conn 对短连接（如 HTTP/1.0 默认无 keepalive）效果不明显，必须用长连接才能体现“连接数累积”和“动态倾斜”。建议用 wrk 或 ab -k 发起持续 30 秒以上的 keepalive 压测：
- 启动 3 个简单 HTTP 服务（如 Python http.server 或 node express），监听 8001–8003，返回固定内容并支持 keepalive
- 用
wrk -t4 -c200 -d30s --latency http://nginx-ip/发起压测 - 实时访问
/status（vts 页面）或解析 JSON 接口，记录三台 server 的active连接数 —— 正常应基本均衡（因初始都为 0，Nginx 会轮询建立首个连接，随后按实际 active 数分配）
三、模拟节点下线：验证自动剔除与连接重分配
手动停掉其中一台（如 kill -9 8002 进程），观察以下现象：
- vts 界面中该 server 状态变为
down，active数快速归零（Nginx 主动断开已有连接或超时关闭） - 新请求不再发往该节点；剩余两台的
active连接数会缓慢上升，且上升速度接近（因 least_conn 在两者间比较） - 若原 8002 上有长连接未及时断开，可通过设置
proxy_next_upstream error timeout http_502;和较短的proxy_timeout加速故障转移
四、模拟节点上线：验证流量渐进回归
重启 8002 服务后，注意：
- Nginx 不会立即恢复该节点 —— 需等待
fail_timeout（默认 10s）结束后，首次健康检查成功才标记为up - 刚上线时
active为 0，而另两台可能仍有几十个连接；此时新请求会明显倾向 8002，使其active数快速上升，另两台增长变缓 - 可通过 vts 的实时折线图看到三台 active 曲线从“2高1低”逐步收敛为“基本持平”，证明 least_conn 正在持续比较并动态导流
整个过程无需改代码或重启 Nginx，核心是依赖 Nginx 内置的连接计数器 + 健康检查 + least_conn 选主逻辑。只要 upstream 配置正确、后端真实支持长连接、监控可观测，就能清晰验证其动态性。
