least_conn算法无需多进程同步，各worker独立统计连接数；调度不均主因是长连接滞留、短连接退化随机分发、健康检查失效、max_conns未设及监控误判。
Nginx 的 least_conn 算法本身不依赖多进程间连接数同步，也不需要同步——它根本就没有“同步”这回事。这是排查前必须厘清的关键点。
每个 worker 进程独立维护自己视角下的后端连接计数，请求由哪个 worker 处理，就只查该 worker 内存里那套数据。不存在跨 worker 通信、共享变量或延迟同步的问题。
所以，如果你观察到“某台后端在不同时间/不同请求上被调度不均”，问题通常不在“同步延迟”，而在于以下几类真实原因：
连接生命周期管理失当
后端未及时关闭连接，或 keepalive timeout 设置过长（如设为 300s），导致大量空闲长连接长期滞留。这些连接被计入活跃数，但实际不承载请求，造成“账面繁忙、实则空闲”的假象。短连接场景下连接数恒为零
若后端每次响应后立即断连（HTTP/1.0 或禁用 keepalive），Nginx 统计的活跃连接数几乎总为 0。此时least_conn退化为近似随机分发，看起来像“调度不准”，实则是连接模型不匹配。健康检查缺失或不敏感
某节点因 GC、锁竞争或网络抖动变慢，但 TCP 连接仍存活、HTTP 响应仍返回 200。least_conn无法识别这种“假活”，继续向其派发请求，导致连接数缓慢爬升却未被剔除。max_conns 未设置，高配节点长期低连接数
高性能服务器处理快、连接释放早，连接数常低于普通节点。若未用max_conns设定容量上限，least_conn会持续倾斜导流，形成事实上的负载不均，而非“同步问题”。监控方式误导判断
仅通过stub_status查看全局连接数，或用 Prometheus exporter 聚合了多个 worker 的指标，容易误以为“某 server 连接数忽高忽低”，其实只是不同 worker 在各自统计，且请求分布本就不完全均匀。
验证是否真有问题，可这样操作：
- 在单 worker 模式下测试（
worker_processes 1;），排除多 worker 干扰； - 用
curl -s http://127.0.0.1:8080/nginx_status查看Active connections和 upstream 各 server 的Active列，确认数值是否稳定反映真实负载； - 抓包或开启
log_format记录$upstream_addr和$upstream_connect_time，比对连接数低的节点是否真有更低建连耗时和更短排队。
本质上，least_conn 是无状态、瞬时决策的算法。它没有“同步延迟”可排查，只有“连接数是否真实”值得深挖。
