Nginx负载均衡健康检查失败，后端节点下线

知识分享

2026-09-29 05:40

11 阅读

Nginx负载均衡健康检查失败，后端节点下线，通常不是Nginx本身挂了，而是它探测后端时没拿到预期响应。
零基础用户先记住一个判断：节点下线是结果，健康检查失败才是原因。
下面按排查顺序讲清怎么定位、修配置、恢复节点并验证。

先确认现象和日志，别急着改配置

登录Nginx所在服务器，先看错误日志里有没有类似 upstream timed out、connect() failed、no live upstreams 的记录。

tail -f /var/log/nginx/error.log

如果日志提示连接被拒绝，多半是后端服务没启动或端口不对；
如果是超时，重点看后端处理是否过慢或网络延迟。
宝塔面板用户可在“网站-设置-配置文件”中查看Nginx配置，日志路径一般在 /www/wwwlogs/ 下。

同时用 curl 直接访问后端节点，绕过Nginx验证服务本身是否正常：

curl -I http://192.168.1.10:8080/health

返回200才说明后端健康检查接口可用。
返回502、403或超时，问题就在后端，不在Nginx。

打开Nginx配置文件，找到 upstream 块，核对节点IP、端口和健康检查相关指令。

upstream backend {
    server 192.168.1.10:8080 max_fails=2 fail_timeout=10s;
    server 192.168.1.11:8080 max_fails=2 fail_timeout=10s;
}

max_fails 表示允许失败次数，fail_timeout 表示失败后暂停多久。
如果这两个值设得太小，网络抖动就会让节点被踢下线。
建议先临时调大观察：

max_fails=3 fail_timeout=30s;

如果用的是Nginx Plus或第三方健康检查模块，还要确认检查路径、超时时间和期望状态码是否匹配后端实际接口。
修改后执行 nginx -t 测试语法，再 nginx -s reload 重载。

节点被下线，常见根因是后端服务异常或端口不通。
在Nginx服务器上依次执行：

telnet 192.168.1.10 8080
ss -lntp | grep 8080

telnet 不通说明网络或防火墙拦截；ss 在Nginx机器上执行只能看本机端口，后端端口要在后端服务器上查。
后端服务器上确认服务进程：

systemctl status your-app
ss -lntp | grep 8080

如果服务没启动，先启动并设开机自启：

systemctl start your-app
systemctl enable your-app

防火墙放行端口示例：

firewall-cmd --add-port=8080/tcp --permanent
firewall-cmd --reload

云服务器还要检查安全组入方向规则是否允许Nginx所在机器访问该端口。

坑一：健康检查接口返回内容太大。 如果检查接口返回大页面，Nginx读取超时也会判失败，建议用轻量 /health 接口。

坑二：后端返回301或302。 默认健康检查可能只认200，重定向会被当成失败，需要确认检查接口直接返回200。

坑三：只改Nginx没重启后端。 后端服务假死时，curl 可能偶尔通，但高并发下持续失败，重启后端往往能立即恢复。

修复后验证：多次请求Nginx入口，观察是否轮询到所有节点。

for i in {1..10}; do curl -s http://你的域名/ | grep -o '节点标识'; done

同时再看错误日志，确认不再出现节点下线相关报错。
如果节点仍反复掉线，把 fail_timeout 调大并持续观察后端CPU、内存和连接数。

健康检查失败一定会导致节点下线吗？ 不一定。
只有失败次数超过 max_fails 且落在 fail_timeout 窗口内，Nginx才会暂时摘除节点。

节点下线后会自动恢复吗？ 会。fail_timeout 过后Nginx会重新尝试探测，后端恢复且检查通过就会重新加入负载。

调大max_fails会不会掩盖真实故障？ 会。
它只适合应对短暂抖动，长期失败还是要查后端和网络，不能只靠调参数。

宝塔面板怎么快速看配置？ 进入“网站-设置-配置文件”，搜索 upstream，修改后点保存并重载Nginx。