开源nginx默认仅支持被动健康检查，需通过max_fails和fail_timeout配置；主动检查须依赖第三方模块如nginx_upstream_check_module，商业版nginx plus才原生支持health_check指令。
Linux 下 Nginx 负载均衡的健康检查，**默认只支持被动检查，主动检查需商业版或第三方模块**。你无法在开源版 Nginx 中直接用 health_check 指令做 HTTP 主动探活——那是 NGINX Plus（商业版）的功能。想在开源版实现类似效果，必须引入第三方模块，比如 nginx_upstream_check_module。
被动健康检查怎么配：max_fails 和 fail_timeout 是关键
这是开源 Nginx 原生支持的方式，靠真实请求失败来“事后标记”后端不可用。
-
max_fails控制连续失败多少次才触发下线，默认是1 -
fail_timeout决定下线时长，默认是10s；超时后会尝试发一个试探请求，成功就恢复 - 失败判定依据包括：连接被拒、超时、收到空响应、
proxy_next_upstream指定的错误码（如502、503、504） - 注意：这个机制不发独立探测包，完全依赖业务请求链路，所以首次发现故障有延迟，且可能把用户请求当探针
示例配置：
upstream backend {
server 192.168.1.10:8080 max_fails=3 fail_timeout=30s;
server 192.168.1.11:8080 max_fails=2 fail_timeout=20s;
}
主动健康检查怎么做：必须用 nginx_upstream_check_module
开源版要真正实现定期发 GET /health 这类探测，得编译安装 nginx_upstream_check_module。它不内置，也不能通过 apt/yum 直接装。
- 必须从源码编译 Nginx，并用
--add-module=加入该模块路径 - 支持
type=http和type=tcp，HTTP 类型可自定义check_http_send和check_http_expect_alive - 务必配
default_down=true，否则新启动时所有节点默认为 up，可能把流量打到未就绪服务上 - 状态页需单独配
location /upstream_status并启用healthcheck_status指令
典型 HTTP 探测配置：
upstream backend {
server 192.168.1.10:8080;
server 192.168.1.11:8080;
check interval=3000 rise=2 fall=5 timeout=1000 type=http;
check_http_send "GET /health HTTP/1.0\r\n\r\n";
check_http_expect_alive http_2xx;
}
为什么 health_check 指令在你的 nginx -V 里找不到
因为它是 NGINX Plus 独占功能，开源版 Nginx 的 configure 输出中不会出现 --with-http_healthcheck_module。运行 nginx -V 2>&1 | grep -o healthcheck 返回空，就是最直接的证据。
- 别信网上某些“已验证可用”的教程——它们大概率混淆了 Plus 版和开源版，或误用了 patch 后的定制包
- 如果你看到配置里写了
health_check却没报错，那说明你用的是 NGINX Plus，或者某个魔改二进制（风险高，不建议生产） - 开源替代方案只有两个：老老实实用被动检查，或自己编译带
nginx_upstream_check_module的 Nginx
容易忽略的兼容性与性能细节
主动检查不是开个开关就完事，几个实际部署中常踩的坑：
- 使用
nginx_upstream_check_module时，upstream必须定义在http块顶层，不能嵌套在server或location里 - HTTP 探测路径（如
/health）必须由后端真实返回 2xx，且不能重定向（302 会被判为失败） - 每个 worker 进程都会独立发探测请求，10 个 worker + 5 台后端 = 每秒最多 50 次探测，注意后端承受力
- 不要把
interval设太小（比如 200ms），Nginx 会合并探测，但过密仍可能引发 TIME_WAIT 暴增
真正上线前，一定要用 tcpdump 抓包确认探测包是否发出、响应是否符合预期——光看状态页容易误判。
