least_conn准确判定空闲节点需验证Nginx是否将新请求实时分发至当前连接数最少的后端，核心是排除残留连接、统计延迟及配置干扰，确保其仅依据worker内活跃TCP连接数（含keepalive空闲连接）进行调度。
测试 least_conn 在空闲节点判定上的准确性，核心是验证 Nginx 是否真把请求分给“此刻连接数最少”的后端，而不是被残留连接、统计延迟或配置干扰带偏。重点不在平均分布，而在新请求到来瞬间的选中逻辑是否干净、及时、可验证。
确认 least_conn 统计的是什么连接
least_conn 只看 Nginx worker 进程内维护的活跃 TCP 连接数，包括：
- 正在处理请求/响应的连接
- keepalive 空闲连接（只要没超时或被关闭，就算在内）
- 后端已断开但 Nginx 尚未感知的“僵尸连接”（此时统计失真）
它完全不看 CPU、内存、响应时间或请求排队数。所以测试前先确保：upstream 块中已启用 keepalive 32;，且 proxy 层显式开启长连接（proxy_http_version 1.1; + proxy_set_header Connection '';），否则短连接会让连接数频繁归零，判定退化为随机。
构造可控的“空闲差”场景
让两台后端呈现明显、稳定的连接数差异，再观察新请求是否稳定落到连接更少的一侧：
- 停掉其中一台（如 192.168.1.10）的所有业务进程，但保持端口监听（用 socat 或 nc -l 模拟“TCP 可通但 HTTP 不响应”）
- 另一台（192.168.1.11）正常提供轻量响应（如返回 static 200，无 sleep）
- 用 wrk -t4 -c10 -d60s 发起低并发压测（避免连接池饱和），同时持续抓取 stub_status 中各 upstream 的 Active 字段
预期结果：192.168.1.10 的 Active 连接数应缓慢上升（因失败重试+连接未释放），而 192.168.1.11 应维持在个位数；新请求应 100% 落到后者——若出现反向分发，说明健康检查缺失或 max_fails 配置过松。
交叉比对连接状态，排除统计误差
不能只信 Nginx 自己报的数字，必须用外部工具实时验证：
- 在 Nginx 本机执行：ss -tn state established | grep :8080 | wc -l，查真实 ESTABLISHED 连接数
- 访问 /nginx_status，提取对应 upstream server 的 Active 值
- 两者偏差超过 2–3 个，需检查：proxy_ignore_client_abort off 是否误配、fail_timeout 是否过长、或后端 keepalive timeout 设置远高于 Nginx
若 ss 查到 5 个连接，stub_status 显示 12 个，大概率存在僵尸连接未清理，least_conn 的“空闲”判定已失效。
验证单次请求的实时选择行为
用 access_log 记录每次请求的真实落点和建连耗时，确认调度不是靠缓存或轮询惯性：
- 配置 log_format 包含：$upstream_addr $upstream_connect_time
- 发起单并发 curl 请求（如 for i in {1..20}; do curl -s http://test/ > /dev/null; sleep 0.5; done）
- 检查日志：所有请求是否一致落到连接数更少的节点；若出现交替或固定打某台，说明 least_conn 未生效（可能配置位置错误、或与其他 hash 指令冲突）
注意：该测试需在无其他流量干扰下进行，确保连接数差异清晰可见。
