Nginx upstream健康监测分被动与主动两类：被动检查原生支持，依赖请求失败触发（max_fails/fail_timeout）；主动检查需nginx_upstream_check_module模块，支持周期性HTTP/TCP探测及响应校验。
被动健康检查：原生支持，开箱即用
这是开源 Nginx 默认具备的能力，无需额外模块，靠真实请求反馈动态标记后端状态。
-
max_fails：设定连续失败次数阈值（如
max_fails=3），超过即标记为不可用 -
fail_timeout：指定该节点被标记为不可用的持续时间（如
fail_timeout=30s），超时后自动重试 - 失败判定包含连接拒绝、超时、空响应，以及
proxy_next_upstream显式指定的错误码（如 502/503/504） - 适合轻量级部署或对首次故障容忍度较高的场景，但无法提前发现“服务启动但接口未就绪”类问题
主动健康检查：精准感知，需第三方模块
要真正实现周期性探测（例如每 3 秒 GET /health），必须引入 nginx_upstream_check_module。
- 需从源码编译 Nginx 并通过
--add-module=加入，不支持 apt/yum 直接安装 - 支持多种探测类型：
tcp、http、ssl_hello、mysql等 - 可自定义请求内容（如
check_http_send "GET /health HTTP/1.0\r\n\r\n"）、期望状态码（如check_http_expect_alive http_2xx）、甚至响应体匹配 - 建议启用
default_down=true，避免新节点启动时误判为可用
HTTPS 后端的实用探测方案
Nginx 开源版无法对 HTTPS 接口做带证书校验的主动探测，但有成熟 workaround：
- 后端在 443 端口同时响应明文 HTTP 健康请求（如
/healthz），Nginx 用 HTTP 探针直连即可 - 避免在探针中配置 SSL 验证逻辑，既简化配置，又降低 Nginx 侧 TLS 开销
- 若后端支持，也可复用同一端口的 HTTP/HTTPS 多路复用能力（如 ALPN），但需服务端配合
参数调优与避坑要点
健康检查不是越频繁越好，需平衡灵敏度与系统开销：
- interval：初始建议设为 5–10 秒；流量高峰时段可适当拉长，避免探测洪峰
-
rise / fall：推荐
rise=2、fall=3起步，兼顾恢复及时性与抗抖动能力 - 探测路径务必轻量（如
/health），禁用涉及数据库或缓存的复杂逻辑 - 配合
stub_status或check_status页面，实时查看各节点状态，便于快速定位异常
