Nginx多后端健康检测需依赖第三方模块（如nginx_upstream_check_module）或Nginx Plus原生功能；开源版不支持主动检查，须编译添加模块，配置interval、rise、fall等参数；Nginx Plus用health_check指令简化配置；被动检测靠max_fails+fail_timeout实现；状态页需配合监控告警。
在 Nginx 中实现多后端健康检测，核心是结合 upstream 模块与第三方模块（如 nginx_upstream_check_module）或利用 Nginx Plus 的原生功能；开源版 Nginx 本身不支持主动健康检查，需通过外部手段或补丁模块增强。
使用 nginx_upstream_check_module（开源常用方案）
这是最广泛采用的开源扩展模块，支持 TCP/HTTP 主动探测，可配合 check_http_send 和 check_http_expect_alive 精确控制检测逻辑。
- 编译时需显式添加该模块（官方源码不含此功能），常见于 OpenResty 或定制编译版本
- 基本配置示例如下：
upstream backend_servers {
server 192.168.1.10:8080;
server 192.168.1.11:8080;
check interval=3 rise=2 fall=5 timeout=1 max_fails=3;
check_http_send "HEAD /health HTTP/1.0\r\n\r\n";
check_http_expect_alive http_2xx http_3xx;
}
其中：interval=3 表示每 3 秒探测一次；rise=2 表示连续 2 次成功则恢复服务；fall=5 表示连续 5 次失败则标记为不可用；max_fails 和 fail_timeout（Nginx 原生参数）仍生效，建议保持一致避免冲突。
借助 Nginx Plus（商业版原生支持）
Nginx Plus 内置 health_check 指令，无需额外编译，配置更简洁、功能更完整（支持 JWT 鉴权、自定义匹配、状态页集成等）。
- 启用主动健康检查只需在 upstream 块中添加：
upstream backend_servers {
server 192.168.1.10:8080;
server 192.168.1.11:8080;
health_check interval=5 fails=3 passes=2 uri=/health;
}
它会定期向每个后端发起 HTTP GET 请求到 /health，根据响应状态码（默认 2xx/3xx 视为健康）和响应体内容（可配合 match 块做正则校验）判断状态。状态页可通过 status 指令暴露实时数据。
被动健康检测（Nginx 开源版内置能力）
虽不能主动发探针，但可通过 max_fails + fail_timeout 实现基于请求失败的自动摘除，适合简单场景。
- 配置示例：
upstream backend_servers {
server 192.168.1.10:8080 max_fails=3 fail_timeout=30s;
server 192.168.1.11:8080 max_fails=3 fail_timeout=30s;
}
当某节点连续 3 次请求失败（连接超时、拒绝、5xx 等），Nginx 将其标记为不可用并持续 30 秒不转发流量；期间若请求成功则立即恢复。注意：该机制依赖真实业务请求触发，无法提前发现静默故障。
搭配状态页与监控告警
无论采用哪种方式，都应暴露健康状态供运维观测。开源版可配合 nginx_upstream_check_module 提供的 /status 接口；Nginx Plus 则直接支持 status 指令。
- 在 server 块中添加状态接口（以开源模块为例）：
location /status {
check_status;
access_log off;
allow 127.0.0.1;
deny all;
}
返回 JSON 或 HTML 格式结果，包含每个节点的当前状态、失败次数、上次检查时间等。建议将其接入 Prometheus（通过 exporter 抓取）或 Zabbix，设置阈值告警。
