least_conn在异构集群中通过实时连接数动态适配：强节点响应快、连接释放早、连接数低而被优先选中，弱节点反之；需配置weight显式体现能力差异，配合keepalive、健康检查与max_conns实现动态收敛。
测试 least_conn 在异构后端集群中的性能，关键不是看“谁分到的请求多”，而是验证它能否让连接负载随节点能力差异动态收敛——高权重/高性能节点承载更多连接，低配节点不被压垮，且整体分布稳定。需从配置对齐、长连接驱动、实时连接观测三方面入手。
一、确保异构能力被 least_conn 正确感知
least_conn 本身不识别 CPU 或内存，只依赖 conns / weight 比值。若未设 weight，所有节点被视为能力相同，异构优势就失效。
- 在 upstream 中为每台后端显式配置
weight，例如：高配机器设weight=4，中配设weight=2，低配设weight=1 - 搭配
max_conns做软性容量兜底，如server 192.168.1.10:8080 weight=4 max_conns=3200;，防止某节点因连接堆积失联 - 禁用与 least_conn 冲突的指令，如
ip_hash或hash $arg_id，否则配置校验失败
二、用长连接压测触发真实连接调度
短连接下 least_conn 等效于轮询，必须构造持续复用的连接场景，才能暴露异构调度效果。
- 后端服务开启 keepalive：Tomcat 配
maxKeepAliveRequests="1000"，Spring Boot 设server.tomcat.connection-timeout=-1 - Nginx upstream 显式启用连接复用：
keepalive 64;（建议 ≤ 后端连接池上限） - 压测客户端保持连接：用
wrk -t4 -c500 -d120s --latency -H "Connection: keep-alive" http://lb/api/test，维持约 500 个长连接并发
三、采集并分析连接分布是否符合异构预期
仅看日志里 $upstream_addr 落点频次不够，要盯住各节点的实时 ESTABLISHED 连接数序列，看其比值是否趋近 weight 反比。
- 每台后端暴露轻量健康接口
/conn-stats，返回当前ss -tn state established | grep :8080 | wc -l结果 - 压测期间每 5 秒轮询所有节点该接口，记录连续时间序列（至少 2 分钟）
- 计算各节点连接数平均值，再算比值：若 A/B/C 的 weight 是 4/2/1，理想连接数比应接近 4:2:1；实际标准差 / 平均值 ≤ 0.25 视为收敛良好
四、排除干扰因素，确认调度逻辑生效
连接数不均衡，未必是 least_conn 失效，更可能是健康检查或 keepalive 设置掩盖了真实状态。
- 启用主动健康检查（Nginx Plus）或强化被动检查：
proxy_next_upstream error timeout http_500 http_502;+max_fails=2 fail_timeout=15s - 检查 access_log 是否含
$upstream_addr $connection_requests $upstream_response_time，确认请求确实落在目标节点，且$connection_requests明显大于 1（证明连接复用） - 用
nginx -V 2>&1 | grep -o with-http_stub_status_module验证 stub_status 已编译，通过/nginx_status查看 worker 连接总数，排除 Nginx 自身瓶颈
