Nginx 报错 no live upstreams 所有后端节点不可用怎么办

核心结论：当 Nginx 日志出现"no live upstreams while connecting to upstream"错误时，通常是因为在 fail_timeout 默认 10 秒内所有后端服务器失败次数超过 max_fails 默认 1 次阈值，导致负载均衡器认为无可用节点。

原因分析

该错误的本质是 Nginx 上游健康检查机制将所有后端服务器标记为不可用状态。从 Nginx 源码 ngx_http_upstream.c 中可以找到关键代码：当 rc 等于 NGX_BUSY 时，就会记录"no live upstreams"的错误。这个返回值来自 ngx_event_connect_peer 函数，该函数在 event/ngx_event_connect.c 中实现，只有在所有后端节点都被标记为失败时才会返回 NGX_BUSY。

典型的触发场景包括：1）健康检查失败，当连续 3 次健康检查失败后，Nginx 会将节点标记为不可用；2）连接超时设置不当，proxy_connect_timeout、proxy_send_timeout、proxy_read_timeout 默认超时时间均为 60 秒，如果业务接口耗时超过此值会被误判为失败；3）负载均衡算法影响，当使用 least_conn 最少连接算法且所有活跃连接数达到上限时，新请求可能被拒绝。

解决方案

方案一：调整健康检查参数

根据实际业务情况调整 max_fails 和 fail_timeout 阈值。参考配置示例：

upstream backend {
    server 192.168.1.1:8080 max_fails=2 fail_timeout=30s;
    server 192.168.1.2:8080 max_fails=2 fail_timeout=30s;
}

某生产环境案例中，原配置为 max_fails=1 fail_timeout=15s，在 15 秒内失败 2 次即认为服务不可用。调整为 max_fails=5 fail_timeout=60s 后，no live upstreams 出现的概率显著减少。但需注意，增大重试次数可能导致请求延迟增加。

方案二：优化超时参数配置

将 Nginx 中的 proxy_connect_timeout 默认超时时间设置大于下游业务最大执行时间。参考配置：

location /api {
    proxy_connect_timeout 120s;
    proxy_send_timeout 120s;
    proxy_read_timeout 120s;
}

某 API 接口平均耗时 65 秒的案例中，由于未调整默认 60 秒超时，导致每分钟都有请求被中断。调整为 120 秒后问题解决。官方文档地址：http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_connect_timeout

方案三：检查系统内核参数

在高压测场景下，可能是服务器访问量大导致内核 netfilter 模块 conntrack 相关参数配置不合理。某 openresty/1.13.6.2 版本压测案例中，通过 sudo sysctl -a | grep conntrack 发现值为 65536，直接提升 4 倍后执行 sudo sysctl -p 使其立即生效，再次压力测试时内核不再出现丢包，Nginx 也不再出现 no live upstreams 错误日志。

方案四：检查主动健康检查模块配置

如果使用了 nginx_upstream_check_module 插件，需注意 check 模块的误用可能导致问题。某案例中，nginx reload 之后一段时间内的访问都是 502，error log 中大量的 no live upstream 日志，原因是对 check upstream module 模块的误用。check 模块默认参数为：interval=30000 fall=5 rise=2 timeout=1000 default_down=true type=tcp。

注意事项

1. 重启应用可临时解决：某生产环境案例显示，每次只要重启 rule-engine 应用，no live upstreams 错误就会消失，基本可断定是服务有部分接口卡死导致 Nginx 认为上游服务接口都不可用。

2. 单台与多台差异：有用户反馈，如果负载均衡目标服务机器两台改为一台反而不会出现这个异常，但服务所在机器压力非常大，这说明问题可能出在 Nginx 服务器本身而非后端。

3. 502 伴随错误：当出现 no live upstreams 时，通常还会伴随大量的"upstream prematurely closed connection while reading response header from upstream"日志，需要综合排查。

4. 连接数监控：当并发连接数超过 worker_connections 设置（默认 512）的 worker_rlimit_nofile 限制时，新连接会被拒绝。可通过 netstat -anp | grep nginx | wc -l 实时监控连接数。

5. 内存泄漏风险：长期运行的 Nginx 可能因第三方模块或配置错误导致内存持续增长，最终触发 oom killer，典型表现是 dmesg 日志中出现 out of memory 记录。

参考来源

来源：Nginx 官方文档 - ngx_http_proxy_module 超时参数说明 (http://nginx.org/en/docs/http/ngx_http_proxy_module.html)

来源：CSDN 博客 - 详解 Nginx no live upstreams while connecting to upstream (2025 年 3 月 3 日)

来源：GitCode 开源社区 - 排查 Nginx-no live upstreams 错误 (2022 年 7 月 29 日)

来源：技术博客 - 压测 nginx 出现 no live upstreams 问题分析 (openresty/1.13.6.2 版本案例，2025 年 11 月 20 日)