Nginx 中健康检查如何配置 proxy_next_upstream 实现后端节点故障自动剔除

Nginx被动健康检查依赖proxy_next_upstream、max_fails和fail_timeout三者协同：前者定义失败重试条件（如error/timeout/5xx），后两者在fail_timeout窗口内累计max_fails次失败后标记节点down并暂停调度30秒，新请求触发试探恢复。

Nginx 本身不提供主动探测后端健康状态的机制（如定期发心跳请求），但可以通过 proxy_next_upstream 配合超时、错误响应等条件，实现“被动健康检查”——即在请求失败时自动尝试下一个 upstream 节点，并结合 max_fails 和 fail_timeout 实现故障节点的临时剔除。

proxy_next_upstream 的作用与触发条件

该指令定义在请求转发到某个 upstream server 失败后，是否尝试重试其他节点。它不决定“是否健康”，而是决定“失败后要不要换人”。常见触发条件包括：

1. error：与后端建立连接、发送请求或读取响应头时发生网络/系统级错误（如 Connection refused、Timeout）
2. timeout：连接、写入或读取超时（需配合 proxy_connect_timeout、proxy_send_timeout、proxy_read_timeout）
3. http_500、http_502、http_503、http_504：收到这些状态码时也视为失败（注意：默认不包含 5xx，必须显式声明）
4. invalid_header：后端返回空或非法响应头（如无 Status 行）

upstream 中配置故障剔除的关键参数

仅靠 proxy_next_upstream 不足以自动剔除节点，必须搭配 max_fails 和 fail_timeout 才能标记节点为“不可用”并暂停转发：

1. max_fails=3：在 fail_timeout 时间窗口内，连续失败 3 次，则标记该 server 为不可用
2. fail_timeout=30s：时间窗口长度；同时它也是“不可用状态”的持续时间 —— 30 秒后自动恢复探测（下一次请求会尝试连接，成功则重新启用）
3. 未设置 max_fails 时默认为 1；未设置 fail_timeout 默认为 10 秒

示例 upstream 配置：

upstream backend {

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 backup;

}

location 中启用重试逻辑

在 proxy_pass 所在 location 块中，明确启用需要的失败类型：

location / {

proxy_pass http://backend;

proxy_next_upstream error timeout http_500 http_502 http_503 http_504;

proxy_next_upstream_tries 3;

proxy_next_upstream_timeout 10s;

proxy_connect_timeout 5s;

proxy_send_timeout 10s;

proxy_read_timeout 10s;

}

1. proxy_next_upstream_tries：最多重试几次（含首次），默认为 0（不重试），设为 3 表示最多试 3 个节点
2. proxy_next_upstream_timeout：整个重试过程总耗时上限，超时后直接返回错误（如 502）
3. 三个 proxy_*_timeout 值共同影响单次请求的失败判定，进而触发 proxy_next_upstream

注意事项与常见误区

1. 该机制是“被动”的：节点只有在被选中且请求失败后才可能被标记为不可用，不会主动探测空闲节点
2. 5xx 错误需显式列出，否则即使后端返回 503，也不会触发重试或计数
3. backup 服务器只在所有非 backup 节点都不可用时才启用，适合做灾备节点
4. 若后端短暂卡顿但未断连，可能返回 200 + 异常 body，此时 proxy_next_upstream 不生效（因未命中任何触发条件），需结合业务层校验或使用 ngx_http_upstream_check_module（第三方模块）做主动健康检查