Nginx基于least_conn实现高并发视频点播需构建完整连接感知体系：least_conn必须置于upstream首行，配合max_conns、健康检查与slow_start，并启用keepalive长连接，否则算法失效。
要让 Nginx 基于 least_conn 真正支撑高并发视频点播（如 HLS/m3u8 或 MP4 流），不能只写一行 least_conn; —— 它必须嵌入完整的连接感知与长连接协同体系，否则在大文件传输、多路并发播放场景下会退化为随机分发。
upstream 必须按规范写对位置和结构
least_conn 只能在 upstream 块第一行出现，且不可加参数、不可与其他策略并存：
- 正确写法：
upstream vod_backend {
least_conn;
server 10.0.1.10:8080 max_fails=2 fail_timeout=15s max_conns=1500 slow_start=30s;
server 10.0.1.11:8080 max_fails=2 fail_timeout=15s max_conns=1500 slow_start=30s;
} - 错误写法：放在
http或location块里；写在server行之后；或与ip_hash共存——Nginx 启动直接报错或静默失效。
每个 server 要配容量感知属性
视频点播请求持续时间长（几秒到数分钟），单靠连接计数容易误判。需用以下三项强制约束节点实际承载能力：
-
max_conns：设为后端服务可稳定维持的并发连接上限（例如 Uvicorn 设置--limit-concurrency 1200，则这里设max_conns=1200） -
max_fails/fail_timeout：启用被动健康检查，防止某台机器因磁盘 I/O 阻塞或网卡打满却仍在收新连接 -
slow_start：新上线节点（如滚动更新后）逐步承接流量，避免瞬间涌入大量视频流压垮缓冲区
必须开启 keepalive + HTTP/1.1 长连接
Nginx 的 least_conn 统计的是它自身与后端之间的活跃 TCP 连接数。如果每次点播都新建短连接，连接数瞬间归零，算法就失去意义：
- 在
upstream块内加：keepalive 64;（建议值 32–128，视 worker 进程数和后端吞吐调整） - 在
location中加：
proxy_http_version 1.1;
proxy_set_header Connection ''; - 后端服务必须支持 HTTP/1.1 keep-alive：例如 Nginx 自身作源站时加
keepalive_timeout 65;；FastAPI/Uvicorn 启动加--keep-alive 65；Tomcat 配置maxKeepAliveRequests="1000"
验证是否真实生效的关键动作
别只看配置 reload 成功——重点观察运行态行为：
- 开启
stub_status，访问/nginx_status查看各后端的Active connections是否随点播并发增长而动态趋近均衡 - 用
curl -I http://gateway/vod/sample.mp4配合后端 access log，确认连续多次请求确实落在不同节点，且优先命中当前连接数更少者 - 监控 P95 响应延迟与连接堆积趋势：若某节点连接数低但首字节延迟飙升，说明健康检查粒度太粗，需补充主动探测（如用
health_check模块定期 GET 小文件）
