least_conn不支持自动剔除高负载节点，需结合主动健康检查（Nginx Plus）或外部脚本+被动检查实现；开源版推荐后端暴露健康端点并配合定时脚本动态重载配置。

nginx 中怎么配置 least_conn 结合健康检查探针自动剔除高负载节点

在 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 不支持主动健康检查，但可通过以下方式模拟“剔除高负载节点”：

Nginx Hosting

通过服务器本地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、错误率），动态调整权重或屏蔽节点（复杂度较高，适合深度定制）。