在 nginx 中，`least_conn` 负载均衡算法结合 `max_fails` 容灾机制，能够实现“优先分配给活跃连接数最少的健康服务器”的策略。具体做法是在 `upstream` 块中同时声明 `least_conn;` 和 `server ... max_fails=n fail_timeout=t;`。当某台后端服务器因故障导致连接失败次数达到 `n` 次时，nginx 会在 `t` 秒内将其标记为不可用并剔除出负载池；一旦恢复，它会自动重新加入集群，且新的请求会避开故障节点，继续流向其他正常节点。
如何配置 least_conn 与 max_fails 参数
要实现这一组合，需要在 Nginx 的配置文件中的 `http` 或 `server` 上下文中定义 `upstream` 模块。核心在于 `least_conn` 指令用于指定调度算法，而 `max_fails` 和 `fail_timeout` 参数则附加在每个具体的 `server` 指令上。`max_fails` 定义了允许的最大失败次数，`fail_timeout` 定义了统计失败次数的时间窗口以及服务器被标记为不可用的持续时间。这种配置确保了流量始终集中在当前状态最好的服务器上。
upstream backend_pool {
least_conn;
server 192.168.1.10:8080 max_fails=3 fail_timeout=30s;
server 192.168.1.11:8080 max_fails=3 fail_timeout=30s;
server 192.168.1.12:8080 max_fails=3 fail_timeout=30s;
}
server {
listen 80;
location / {
proxy_pass http://backend_pool;
}
}上述配置中，Nginx 会将请求发送给当前活跃连接数最少的服务器。如果 `192.168.1.10` 连续 3 次在 30 秒内响应失败（如连接超时或返回 502/504），它将被暂时移除。在这 30 秒内，所有新请求将仅在 `.11` 和 `.12` 之间根据连接数进行分配。
max_fails 触发后的故障转移行为是怎样的
当 `max_fails` 条件被触发时，Nginx 的行为是立即停止向该特定服务器发送新请求，而不是等待其完全恢复。这种机制称为“软故障隔离”。在 `fail_timeout` 设定的时间窗口内，Nginx 会持续监控该服务器的健康状态。如果在此期间服务器恢复了响应，Nnginx 不会立即将其放回负载池，而是等到 `fail_timeout` 计时结束后，再尝试发送一个探测请求。如果探测成功，该服务器才重新进入 `least_conn` 的候选列表。这种设计避免了“惊群效应”或过早将流量打回尚未完全稳定的节点。
# 模拟测试脚本：快速发送请求以触发 max_fails
for i in {1..10}; do
curl -s -o /dev/null -w "%{http_code}" http://localhost/api/test || echo "Failed"
done
# 观察 nginx error.log 中的 upstream connection refused 或 timeout 记录
# 随后检查 active connections 分布，确认故障节点是否被剔除在实际操作中，可以通过模拟后端服务宕机来验证此行为。当后端服务停止响应时，Nginx 会在 `error.log` 中记录上游连接失败的信息。此时，通过查看 Nginx 的状态页（需开启 `stub_status`）或监控工具，可以观察到故障节点的连接数不再增加，而其他健康节点的连接数上升，体现了 `least_conn` 的动态调整能力。
当所有服务器都达到 max_fails 时会发生什么
这是一个极端但必须考虑的场景。如果所有配置的 `server` 都在同一个 `fail_timeout` 周期内达到了 `max_fails` 阈值，Nginx 会将整个 `upstream` 组标记为不可用。此时，客户端发起的请求将直接收到 502 Bad Gateway 错误，因为没有任何健康的后端节点可供 `least_conn` 算法选择。Nginx 不会无限重试失败的节点，也不会尝试连接未配置的节点。要解决这一问题，通常需要引入健康检查代理、使用更细粒度的 `max_fails` 值，或者确保后端服务的高可用性架构，避免同时全量宕机。此外，Nginx 默认保留最后一个可用的服务器作为“最后手段”，但在所有节点均失效的情况下，这一机制也无法生效，必须依赖上层网关或 DNS 层面的容灾策略。
