least_conn不支持自动剔除高负载节点，需结合主动健康检查（Nginx Plus）或外部脚本+被动检查实现；开源版推荐后端暴露健康端点并配合定时脚本动态重载配置。
在 Nginx 中，least_conn 本身**不支持自动剔除高负载节点**，它只负责将新连接转发给当前活跃连接数最少的后端；而“高负载”（如 CPU、内存、响应延迟高）无法被原生 least_conn 感知。要实现“基于健康检查动态剔除高负载节点”，必须结合 主动健康检查（active health check） + 自定义指标判断逻辑（通常需外部配合），Nginx 开源版能力有限，推荐使用 Nginx Plus 或通过 上游服务暴露健康端点 + 被动检查 + 手动/脚本干预 的组合方案。
✅ 使用 Nginx Plus（推荐）：内置 active health check + least_conn + 自定义状态探针
Nginx Plus 支持对 upstream server 执行周期性 HTTP/TCP 主动探测，并可基于响应内容、状态码、响应时间等条件判定节点健康状态。配合 least_conn，可自然实现“仅向健康且连接数最少的节点分发请求”。
配置示例：
upstream backend {
least_conn;
<pre class="brush:php;toolbar:false;"># 启用主动健康检查
zone backend 64k;
server 10.0.1.10:8080 max_fails=2 fail_timeout=30s;
server 10.0.1.11:8080 max_fails=2 fail_timeout=30s;
server 10.0.1.12:8080 max_fails=2 fail_timeout=30s;}
定义健康检查规则（Nginx Plus 特有）
health_check interval=5 fails=2 passes=2; health_check_http_200_ok; # 要求返回 200 health_check_expect status 200; health_check_expect body ~ "healthy"; # 响应体含 healthy 字符串 health_check_timeout 3s;
⚠️ 注意：
- health_check 指令只能出现在 location 块中，且必须搭配 proxy_pass 到该 upstream；
- 探针路径默认为 /，可通过 health_check uri=/health 自定义；
- 若后端 /health 接口能反映“高负载”（例如：响应 503 或 body 含 "overloaded"），Nginx Plus 会自动标记该 server 为 unhealthy，least_conn 将跳过它。
? 开源 Nginx 方案：被动检查 + 外部脚本 + 动态配置重载
开源版 Nginx 不支持主动健康检查，但可通过以下方式模拟“剔除高负载节点”：
- 后端服务提供
/health?detailed=1接口，返回 JSON 如：{"status":"up","load":0.92,"rt_ms":420}； - 编写定时脚本（如 Python/Bash），定期调用所有后端健康接口；
- 当某节点
load > 0.8或rt_ms > 300，将其从 upstream 配置中临时注释或移除； - 执行
nginx -s reload生效（注意 reload 频率不宜过高，建议 ≥30s 间隔）； - 配合
least_conn和max_conns（限制单节点最大并发连接数）进一步防止单点过载。
示例 upstream（配合脚本维护）：
upstream backend {
least_conn;
# max_conns 1024; # 可选：硬限流，防止某节点连接数爆炸
server 10.0.1.10:8080;
server 10.0.1.11:8080;
server 10.0.1.12:8080;
}
? 补充增强策略（开源/Nginx Plus 均适用）
单靠连接数或简单健康检查仍不够精细，建议叠加以下机制：
-
启用
keepalive：减少连接建立开销，让least_conn统计更稳定； -
设置
proxy_next_upstream error timeout http_500 http_502 http_503 http_504：发生错误时自动重试其他节点（需配合least_conn的实时性）； - 后端主动上报指标到 Prometheus + Alertmanager，触发 Webhook 调用运维脚本下线节点；
- 用 OpenResty + Lua 在 Nginx 层做轻量级负载感知（如记录每个 upstream server 的平均 RT、错误率），动态调整权重或屏蔽节点（复杂度较高，适合深度定制）。
❌ 常见误区提醒
不要误以为以下做法可行：
-
least_conn会读取后端的/proc/loadavg—— 它不会； - 仅靠
max_fails/fail_timeout就能识别“高负载”—— 它只响应连接失败或超时，不感知业务延迟或资源饱和； - 在
upstream中写health_check（开源版报错）—— 该指令仅 Nginx Plus 支持； - reload 配置太频繁导致 worker 进程抖动 —— 应加锁+限频+灰度验证。
真正落地时，优先评估是否需要 Nginx Plus 许可证；若必须用开源版，建议以“后端自报告 + 外部闭环控制”为主，Nginx 专注稳定转发，把复杂决策交给更灵活的调度层。
