Nginx负载均衡健康检查配置详解：被动检测与主动检测的完整实战指南

什么是Nginx健康检查

在负载均衡场景中，后端服务器难免会出现故障。如果没有健康检查机制，Nginx会持续将请求转发到已经宕机的服务器，导致用户访问失败。健康检查的作用就是自动识别故障节点并暂时将其剔除，等服务器恢复后再重新纳入负载均衡池。

Nginx的健康检查分为两种模式：

• 被动健康检查：Nginx原生支持，通过分析实际请求的响应结果判断服务器状态
• 主动健康检查：定期发送探测请求，需要商业版Nginx Plus或第三方模块支持

一、被动健康检查（原生支持）

被动健康检查是Nginx开源版本自带的机制，无需额外安装模块。它通过两个关键参数控制：max_fails和fail_timeout。

1. max_fails参数详解

max_fails设置在fail_timeout时间段内允许的最大失败次数。当失败次数达到这个阈值，服务器会被标记为不可用。

参数说明：

• 默认值：1次
• 设置为0表示不进行健康检查
• 失败判定依据：超时、连接失败、HTTP 500/502/503/504等错误

2. fail_timeout参数详解

fail_timeout有两层含义：

1. 统计周期：在这个时间段内累计失败次数
2. 冷却时间：服务器被标记不可用后，持续多久才会再次尝试

默认值：10秒

3. 基础配置示例

upstream backend {
    server 192.168.1.101:8080 max_fails=3 fail_timeout=30s;
    server 192.168.1.102:8080 max_fails=3 fail_timeout=30s;
    server 192.168.1.103:8080 backup;
}

server {
    location / {
        proxy_pass http://backend;
        proxy_next_upstream error timeout http_500 http_502 http_503 http_504;
    }
}

配置解读：

• 每台服务器在30秒内失败3次后会被标记为不可用
• 不可用状态持续30秒后才会重新尝试
• 103服务器作为backup，只有前两台都不可用时才会启用
• proxy_next_upstream定义了哪些情况算作失败并触发重试

4. proxy_next_upstream参数

这个指令控制哪些错误会触发请求转发到下一台服务器：

proxy_next_upstream error timeout http_500 http_502 http_503 http_504 non_idempotent;

可选值说明：

• error：与服务器建立连接、发送请求或读取响应时出错
• timeout：连接超时
• invalid_header：响应头无效
• http_500、http_502、http_503、http_504：对应的HTTP状态码
• non_idempotent：允许非幂等方法（POST、LOCK、PATCH）重试

二、主动健康检查

被动检查的局限在于：只有当请求到达时才会发现问题。如果某台服务器在空闲时宕机，Nginx不会察觉，直到下一个请求发过去才发现。主动健康检查可以解决这个问题。

1. Nginx Plus商业版方案

Nginx Plus提供了完整的主动健康检查功能：

upstream backend {
    zone backend 64k;
    server 192.168.1.101:8080;
    server 192.168.1.102:8080;
}

server {
    location / {
        proxy_pass http://backend;
        health_check interval=5s fails=3 passes=2;
    }
}

参数说明：

• interval：检查间隔，默认5秒
• fails：连续失败几次标记为不健康
• passes：连续成功几次标记为健康

2. 开源方案：nginx_upstream_check_module

对于使用Nginx开源版的用户，可以通过第三方模块实现主动健康检查：

安装步骤：

# 下载模块
git clone https://github.com/yaoweibin/nginx_upstream_check_module.git

# 打补丁（根据Nginx版本选择）
cd nginx-1.24.0
patch -p1 < ../nginx_upstream_check_module/check_1.24.0+.patch

# 重新编译
./configure --add-module=../nginx_upstream_check_module
make && make install

配置示例：

upstream backend {
    server 192.168.1.101:8080;
    server 192.168.1.102:8080;
    
    check interval=3000 rise=2 fall=3 timeout=1000 type=http;
    check_http_send "GET /health HTTP/1.0\r\n\r\n";
    check_http_expect_alive http_2xx http_3xx;
}

参数详解：

• interval：检查间隔（毫秒）
• rise：连续成功几次认为服务器恢复
• fall：连续失败几次认为服务器宕机
• timeout：检查超时时间（毫秒）
• type：检查类型，支持tcp、http、ssl_hello、mysql、ajp

3. 查看健康状态页面

模块还提供了状态查看页面：

server {
    listen 8080;
    location /status {
        check_status;
        access_log off;
        allow 192.168.1.0/24;
        deny all;
    }
}

访问http://服务器IP:8080/status即可看到后端服务器健康状态。

三、实战场景配置

场景1：高可用API网关

upstream api_servers {
    zone api_servers 64k;
    
    server 10.0.0.101:8000 max_fails=2 fail_timeout=10s;
    server 10.0.0.102:8000 max_fails=2 fail_timeout=10s;
    server 10.0.0.103:8000 backup;
    
    keepalive 32;
}

server {
    listen 80;
    
    location /api/ {
        proxy_pass http://api_servers;
        proxy_http_version 1.1;
        proxy_set_header Connection "";
        proxy_connect_timeout 5s;
        proxy_read_timeout 10s;
        proxy_next_upstream error timeout http_500 http_502 http_503;
    }
}

场景2：Web服务集群

upstream web_cluster {
    server 192.168.10.1:80 weight=5 max_fails=3 fail_timeout=30s;
    server 192.168.10.2:80 weight=3 max_fails=3 fail_timeout=30s;
    server 192.168.10.3:80 weight=2 max_fails=3 fail_timeout=30s;
    server 192.168.10.4:80 backup;
}

server {
    location / {
        proxy_pass http://web_cluster;
        proxy_next_upstream error timeout invalid_header http_500 http_502 http_503 http_504;
        proxy_next_upstream_tries 3;
        proxy_next_upstream_timeout 30s;
    }
}

四、常见问题排查

1. 服务器频繁被标记不健康

可能原因：

• 后端服务响应慢，触发超时阈值
• max_fails设置过低
• 网络抖动导致连接失败

解决方案：适当增大fail_timeout和proxy_read_timeout值

2. 故障服务器迟迟不被剔除

可能原因：

• max_fails设置过大
• 请求量太小，短时间内未达到失败阈值

解决方案：降低max_fails值或使用主动健康检查

3. backup服务器无法启动

可能原因：backup参数与某些负载均衡方法不兼容

解决方案：backup不能与hash、ip_hash、random方法一起使用

五、最佳实践建议

1. 合理设置超时时间：fail_timeout不宜过短，建议30秒以上
2. 配置backup服务器：确保至少有一台备用节点
3. 使用zone指令：共享内存确保worker进程状态同步
4. 监控健康状态：定期检查日志，及时发现异常
5. 配合负载均衡算法：least_conn配合健康检查效果更好

相关文章推荐

• Nginx负载均衡健康检查配置详解：被动检测与主动检测的完整实战指南
• Nginx加权轮询weight配置详解：从原理到实战的完整指南
• Nginx least_conn最少连接算法原理：让负载均衡更智能的完整指南

总结

Nginx健康检查是保障服务高可用的关键机制。被动检查配置简单，适合大多数场景；主动检查响应更快，适合对可用性要求极高的业务。实际部署时，建议根据业务特点选择合适方案，并配合合理的超时参数和重试策略，构建稳定可靠的后端服务架构。