least_conn算法本身轻量，仅统计各后端活跃连接数并做简单比较；在多站点共用Nginx时，需为每个业务域定义独立upstream块以隔离连接统计，配合合理keepalive值（16～32）、禁用冗余指令及按需启用健康检查，方可兼顾轻量与实效。
Nginx 的 least_conn 算法本身就很轻量——它不采集 CPU、内存或响应时间，只维护每个 upstream 中各后端的活跃连接计数，每次新请求到来时做一次简单比较。但在大量虚拟主机（多站点）共用同一 Nginx 实例的环境中，要真正保持轻量且不失效，关键不是“减少计算”，而是避免配置膨胀和统计失真。
确保 least_conn 按 upstream 隔离，不跨站点干扰
每个站点（或业务域）应定义独立的 upstream 块，least_conn 只在各自块内生效：
- 不要用一个全局 upstream 承载所有后端，否则连接数混杂，A 站点的长 WebSocket 连接会拉高 B 站点的“账面负载”
- 示例：为电商站、后台 API、文件服务分别建
upstream shop_backend、upstream admin_api、upstream file_proxy，各自配least_conn - 同一 upstream 内 server 数建议 ≤ 10 台；超量不会报错，但遍历开销略增（实际影响微乎其微）
复用 keepalive 连接池，而非为每个站点单独配大值keepalive N 是 per-worker、per-upstream 的缓存上限，不是全局连接数：
- 多站点共用同类后端时，可共享同一个 upstream（如所有静态资源都走 CDN 回源集群），复用连接池降低系统 fd 消耗
- 若后端差异大（比如 PHP-FPM 和 Node.js 混用），必须分 upstream，避免 keepalive 连接因协议/超时不兼容被频繁断开重连
- 典型值
keepalive 16～32已足够：过大会占用过多空闲连接（计入活跃数），过小则复用率低，连接数抖动加剧
禁用冗余指令，防止隐式开销
- 不在
http或server块里写least_conn：语法错误直接导致 reload 失败，排查成本高 - 不混用
ip_hash、hash $host等策略：Nginx 会拒绝加载，且错误日志不易定位 - 不给
least_conn加任何参数（如least_conn timeout=5s）：被静默忽略，还可能触发 warning
健康检查按需启用，不一刀切
- 对内部稳定服务（如同机房数据库代理），用轻量被动检查：
max_fails=2 fail_timeout=15s即可 - 对外网或弱网络后端，才启用主动
check（需 OpenResty 或第三方模块），避免每秒探活增加 CPU 和网络负担 - 所有健康检查都应设合理
interval（≥3s）和timeout（≤1s），避免探测本身成为压力源
基本上就这些。
