least_conn是nginx内置的动态负载均衡策略，优先将新连接分发给当前活跃tcp连接数最少的健康后端，专为视频流等长连接场景设计，需配合keepalive、max_conns、健康检查及stub_status验证效果。
least_conn 是处理视频流这类长连接业务最匹配的内置负载均衡策略——它不看请求次数、不比响应时间，只盯住每个后端当前“还连着多少个客户端”，新连接自然流向最空闲的节点。对 RTMP/HLS 推流、WebRTC 信令、HTTP/1.1 持久流式响应等场景，轮询容易把流量持续压向正在卡顿的节点，而 least_conn 能实时绕开，避免单点堆积和雪崩。
基础配置必须写对位置和结构
least_conn 只能出现在 upstream 块的第一行，否则 Nginx 启动直接报错：
- 正确写法：upstream video_cluster { least_conn; server 10.0.1.10:8080; server 10.0.1.11:8080; }
- weight 参数会被静默忽略，别写 server ... weight=2；想体现节点能力差异，改用 max_conns=1500（高配推流机）或 max_conns=600（普通边缘节点）
- 同一 upstream 中禁用 ip_hash、hash、least_time 等互斥指令
让连接数真实反映视频流压力
视频流连接往往持续几十秒到数小时，若 Nginx 和后端之间不复用连接，活跃连接数始终接近 0，least_conn 就退化成随机分配：
- 在 upstream 块中加：keepalive 64;（每个 worker 最多缓存 64 条空闲长连接）
- 在 proxy_pass 所在 location 中加：proxy_http_version 1.1; 和 proxy_set_header Connection '';
- 后端服务需支持 keep-alive：Nginx-RTMP 模块默认支持；FFmpeg 推流目标如 SRS 需开启 http_keepalive_timeout；WebRTC 信令服务（如 Janus）要确认 HTTP/1.1 复用已启用
防卡死、防堆积的关键保护机制
一个卡住的 HLS 切片生成或 WebRTC 数据通道异常，可能让连接长期挂起却不释放，least_conn 无法识别这种“假空闲”：
- 为每个 server 设置 max_conns=800;（举例），达到即剔出调度池，防止慢流锁死整条连接队列
- 配置健康检查：max_fails=2 fail_timeout=10s;，快速摘除僵死节点
- 设 proxy_read_timeout 90;（略高于视频流 P99 处理耗时），超时即断开并重试其他节点
- 新扩容节点加 slow_start=60s;，避免冷启动瞬间被大量流冲击
验证是否真正在按流压力调度
改完配置后，不能只看 Nginx 是否启动成功，要观察实际行为：
- 开启 stub_status，在 server 块中加：location /nginx_status { stub_status; }，访问后查看各 server 的 Active 连接数是否随并发流增加趋于均衡
- 对比后端真实连接数：ss -tn src :8080 | grep ESTAB | wc -l，应与 Nginx 统计基本一致
- 压测时用多路 FFmpeg 拉流（如 50 路 HLS），观察是否有节点连接数持续偏高、超时率明显上升——若有，说明 max_conns 或 timeout 设置不合理
