nginx upstream健康检查分被动与主动两类：被动依赖请求失败触发（max_fails/fail_timeout），开源版原生支持；主动需nginx_upstream_check_module第三方模块或nginx plus商业版，支持周期性http/tcp探测及响应内容校验。
Nginx 的 upstream 健康度探测分两种本质路径：被动检查靠请求反馈，主动检查靠独立探针。开源版默认只支持前者，后者需额外模块或商业版。
被动健康检查（原生支持，无需编译）
这是最简方式，不发额外探测包，而是根据真实请求是否失败来动态标记后端状态： - max_fails：连续失败多少次后，将该 server 标记为不可用（例如设为 3） - fail_timeout：被标记为不可用的持续时间（单位秒），超时后会尝试恢复连接 - 失败判定包括：连接拒绝、超时、空响应、或 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 backup;
}
注意：它无法提前发现“服务已启动但接口卡死”或“/health 端点未就绪”的情况；首次故障暴露有延迟，且可能把用户请求当探针。
主动健康检查（需第三方模块）
要真正实现周期性 HTTP 探测（如每 3 秒 GET /health），必须使用 nginx_upstream_check_module： - 需从源码编译 Nginx，并通过--add-module= 加入该模块
- 不支持 apt/yum 直接安装，也不能在运行中热加载
- 支持 TCP、HTTP、SSL Hello 等多种探测类型，可自定义请求头、状态码预期、响应体匹配
典型 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;
}
关键参数说明：
- interval=3000：每 3000 毫秒探测一次
- rise=2：连续 2 次成功即恢复上线
- fall=5：连续 5 次失败才下线
- check_http_expect_alive http_2xx：仅当返回 2xx 状态码才视为健康
- 建议加
default_down=true，避免新启动时误将未就绪节点当作可用
HTTPS 后端的健康检查怎么做
Nginx 开源版不支持对 HTTPS 接口本身做带证书校验的主动探测，但有实用解法： - 后端服务在 HTTPS 端口上同时响应明文 HTTP 健康请求（如 /healthz），Nginx 用 HTTP 探针直连 443 端口即可 - 或更稳妥：后端额外暴露一个 HTTP 健康端口（如 8081），专供 Nginx 探测 - 实际转发到 HTTPS 后端时，仍需配置proxy_ssl_verify on、proxy_ssl_trusted_certificate 等确保通信安全
Nginx Plus（商业方案）
如果你用的是 NGINX Plus，直接用原生health_check 指令：
upstream backend {
server 192.168.1.10:8080;
server 192.168.1.11:8080;
health_check interval=5 fails=3 passes=2 match=health_ok;
}
match health_ok {
status 200;
header Content-Type = "application/json";
body ~ "healthy.*true";
}
它还自带实时 dashboard 和 API，适合需要可观测性与自动化联动的生产环境。
