least_conn调度一致性验证需确认新请求始终落在活跃连接数最少的后端节点上。关键步骤包括：启用least_conn与keepalive、统一网关upstream配置、通过stub_status或第三方模块观测连接数、长连接压测追踪流向，并排查健康检查不同步、连接未释放及权重不一致等诱因。
验证 least_conn 在多网关架构下的调度一致性，核心是确认“新请求是否确实落在当前活跃连接数最少的后端节点上”，而不是依赖轮询、IP哈希或随机分发。它不看请求数、CPU 或响应时间，只看 Nginx 与后端之间维持的 TCP 连接数。以下从实操角度给出关键验证路径。
确认 upstream 配置已启用 least_conn 并启用连接复用
确保每个网关节点上的 upstream 块明确声明 least_conn，且搭配 keepalive（否则短连接下连接数瞬时波动大，无法体现算法效果）：
- 配置示例必须包含
least_conn;和keepalive N;（如 keepalive 32） - 同时设置
proxy_http_version 1.1;和proxy_set_header Connection '';，保证上游连接可复用 - 所有网关节点使用完全一致的 upstream 定义（包括 server 地址、端口、weight、max_fails 等），避免因配置差异导致行为不一致
实时观测各后端的活跃连接数
Nginx 自身不直接暴露每个 backend 的当前连接数，但可通过组合方式间接验证：
- 启用 stub_status 模块（需编译时含 --with-http_stub_status_module），在 location 中暴露连接统计：
location /nginx_status { stub_status; } - 配合 第三方模块 ngx_http_upstream_check_module（推荐）或商业版 NGINX Plus，可获取每个 server 的 active conn 数、健康状态、失败计数等详细指标
- 用
ss -tnp | grep :<backend_port></backend_port>在后端机器上手动统计 ESTABLISHED 连接，比对多个网关发来的连接分布是否随负载变化而动态偏移
构造可控长连接压测并追踪请求流向
用工具模拟真实长连接场景（如 HTTP/1.1 + keep-alive 或 WebSocket），避免短连接干扰：
- 用
ab -k -n 1000 -c 50 http://gateway/test或更精准的hey -c 100 -z 30s -m GET http://gateway/test - 在压测期间，持续轮询各后端的连接数（如每秒一次
ss -tn state established '( dport = :8080 )' | wc -l） - 观察趋势：当某台后端因慢响应或阻塞积压连接时，其余网关是否同步将后续新连接导向连接数更低的节点——若多个网关各自独立决策但结果高度趋同，说明 least_conn 调度逻辑一致生效
排查常见不一致诱因
多网关下出现“看起来没走 least_conn”的主因往往不在算法本身，而在环境偏差：
-
健康检查不同步：某网关因网络抖动标记某 backend 为 down，其他网关仍认为其 healthy，导致连接数统计对象不一致；统一使用 active check + 相同
max_fails/fail_timeout -
连接未及时释放：后端 linger 时间过长或 close_wait 大量堆积，Nginx 仍将其计入 active conn；检查后端 socket 关闭逻辑和内核参数（如
net.ipv4.tcp_fin_timeout） -
权重未显式设为 1 或被忽略：least_conn 内部按
conns / weight计算，若某 server 隐式 weight=1、另一台未写 weight 但实际被解析为 1，没问题；但若混用 weight=2 和 weight=1，会改变排序逻辑，需统一显式声明
