least_conn按实时连接数调度，可通过stub_status查看各后端活跃连接数，并结合自定义日志与短时压测验证其避让忙节点的行为。
直接观察 least_conn 的分发行为比猜更有说服力。它不显示在日志里，也不返回 header，但可以通过组合监控、压测和状态接口，清晰验证它是否真正在按“连接数最少”调度。
用 stub_status + 自定义日志确认连接数分布
Nginx 自带的 stub_status 模块能实时看到每个 upstream server 的活跃连接数，这是 least_conn 决策的唯一依据：
- 先在 Nginx 配置中启用状态页：
location /nginx_status { stub_status; }，并限制访问来源 - 确保 upstream 块中已正确配置
least_conn;和各server行（含max_fails等基础健康参数） - 启动后，用
curl http://localhost/nginx_status查看类似输出：Active connections: 123<br>server accepts handled requests<br> 12345 12345 56789<br>Reading: 0 Writing: 3 Waiting: 120<br>upstream: 192.168.1.10:8080 (12) 192.168.1.11:8080 (8)
括号里的数字就是当前该后端的活跃连接数 - 配合
log_format记录$upstream_addr和$upstream_connect_time，可交叉验证：连接数少的节点，是否确实承接了更多新请求
用短时压测对比轮询与 least_conn 的连接堆积差异
轮询会平均分发请求，least_conn 在后端响应不均时会主动避让忙节点——这个差异在压测中非常明显：
- 准备两个后端服务：一个响应快（如返回固定 JSON，P99
- 分别用
round_robin和least_conn配置 upstream，用ab -n 1000 -c 50或wrk -t4 -c100 -d30s发起并发请求 - 压测中反复调用
/nginx_status，你会看到：
— 轮询下，两台后端连接数基本持平（比如 25 vs 26）
— least_conn 下，慢节点连接数快速逼近上限（如 48），快节点始终维持低位（如 2–5） - 注意：需关闭或统一后端 keepalive 设置，避免连接复用干扰连接数变化节奏
用 curl + netstat 检查单次请求的真实流向
当需要确认某一次请求是否真的打到了连接数最少的节点，可以临时开启 debug 日志或使用网络层验证：
- 在测试机上执行：
curl -v http://your-nginx/health，同时在 Nginx 服务器运行：sudo ss -tnp | grep :8080（假设后端端口是 8080） - 观察输出中 ESTAB 状态的连接对，例如：
192.168.1.5:54321 → 192.168.1.10:8080，就能确认本次请求走的是哪台后端 - 多执行几次，配合
/nginx_status当前连接数快照，可人工比对：“连接数为 3 的 A 节点是否被选中，而连接数为 12 的 B 节点被跳过” - 若想自动化，可用脚本循环发起请求 + 抓取
ss输出 + 解析 IP，生成分发路径热力图
检查配置是否生效的硬性信号
least_conn 不生效往往不是算法问题，而是配置被覆盖或降级：
- 运行
nginx -t后，检查错误日志是否有invalid parameter "least_conn"——说明语法位置错误（必须是 upstream 块首行） - 查看
error.log是否出现upstream zone is not defined（若用了least_time误配）或ip_hash and least_conn cannot be used together - 用
nginx -T | grep -A 10 "upstream backend"确认最终加载的配置中，least_conn;确实出现在 upstream 块第一行，且没有其他冲突指令 - 如果所有 server 都标记了
down或全部max_conns已满，least_conn 会静默 fallback 到轮询，此时/nginx_status中 upstream 行会显示(down)或连接数恒为 0
