Nginx后端健康检查分被动与主动两种：被动靠请求失败自动标记节点（max_fails/fail_timeout+proxy_next_upstream），开箱即用；主动需第三方模块nginx_upstream_check_module，定时HTTP探活，支持定制探测与状态页监控。
Nginx 实现后端健康检查，核心在于让负载均衡器能“自己发现”哪台后端挂了、哪台刚恢复，而不是等用户请求失败才反应。这需要区分两种逻辑：被动靠真实请求反馈，主动靠独立心跳探测。选哪种，取决于你对故障发现速度、运维复杂度和系统稳定性的要求。
被动健康检查（开箱即用，适合大多数场景）
这是 Nginx 开源版原生支持的方式，不需要额外模块，靠代理请求的失败行为自动调整节点状态。
- 在
upstream块中为每个后端明确设置max_fails和fail_timeout：-
max_fails=3表示连续 3 次失败才标记该节点不可用 -
fail_timeout=30s表示该节点被屏蔽 30 秒，之后自动重试一次
-
- 同时在
location中启用proxy_next_upstream，定义哪些响应算“失败”并触发重试：- 推荐值：
error timeout http_500 http_502 http_503 http_504 - 避免加入
http_404或invalid_header，除非业务确认这些一定代表后端异常
- 推荐值：
- 注意：它不发心跳，没请求就不会检查；新服务刚启动但还没 ready，流量仍可能打过去
主动健康检查（需编译模块，适合高可用要求场景）
要真正实现“定时探活”，必须使用 nginx_upstream_check_module 第三方模块。它独立于业务流量，每几秒就发一次 GET 请求到 /health 这类专用接口。
- 编译安装前先验证：运行
nginx -V 2>&1 | grep upstream_check，无输出说明未启用 - 启用后，在
upstream块中添加check指令：-
check interval=3 rise=2 fall=5 timeout=1 type=http -
rise=2防止偶发抖动误恢复，fall=5避免单次丢包就下线
-
- 必须配合定制探测行为：
-
check_http_send "GET /health HTTP/1.1\r\nHost: api.example.com\r\nConnection: close\r\n\r\n" -
check_http_expect_alive http_2xx，但更稳妥的是后端返回 JSON 并校验{"status":"UP"}
-
- 每个
server行要设max_fails=0 fail_timeout=0，禁用被动机制干扰 - 别和
keepalive共存，否则 Nginx 启动失败
HTTPS 后端的健康检查要点
后端是 HTTPS 不代表健康检查也得走 HTTPS。主流做法是：后端在 HTTPS 端口同时响应 /health 的明文 HTTP 请求（Nginx 发过去即可），或单独暴露一个 HTTP 健康端口。
- 若必须走 TLS，Nginx 开源版不支持带证书校验的主动探针，只能依赖被动检查 +
proxy_ssl_verify on等参数保障业务通信安全 - 关键配置包括：
-
proxy_ssl_protocols TLSv1.2 TLSv1.3 -
proxy_ssl_trusted_certificate /path/to/ca.crt（自签证书必须配） -
proxy_ssl_name "backend.example.com"（匹配证书 CN 或 SAN）
-
暴露状态页与监控闭环
加一行就能看到实时节点状态，方便排查和对接 Prometheus：
location /status {
check_status;
access_log off;
allow 127.0.0.1;
deny all;
}访问 /status 可查看各节点 IP、端口、当前 up/down 状态、失败次数、最近检测时间。务必限制访问来源，不能对外暴露。
不复杂但容易忽略
