Nginx高可用需结合主动与被动健康检查：被动检查依赖请求失败触发，通过max_fails和fail_timeout控制节点摘除；主动检查需编译nginx_upstream_check_module，支持HTTP/TCP等探测，配置interval、rise、fall、timeout等参数，并暴露轻量健康端点。
要让 Nginx 真正支撑后端服务的高可用，光靠默认轮询或简单容错远远不够。核心在于用好 upstream 健康检查——不是等用户请求失败才反应，而是主动探测、提前隔离、快速恢复。
区分被动与主动两类检查机制
被动检查是 Nginx 开源版原生支持的能力，无需额外模块：
- 依赖真实请求失败触发，通过 max_fails（如设为 2）和 fail_timeout（如设为 15s）控制节点摘除与恢复节奏
- 失败判定涵盖连接拒绝、超时、空响应，以及 proxy_next_upstream 显式指定的错误码（如 502/503/504）
- 适合轻量部署，但无法发现“进程在、接口卡死”或“证书过期但端口通”这类静默故障
主动检查需引入 nginx_upstream_check_module 模块：
- 必须从源码编译 Nginx 并添加该模块，apt/yum 安装的包默认不包含
- 支持 HTTP、TCP、SSL Hello、MySQL 等多种探测类型，可周期性发探针（如每 3 秒 GET /health）
- 能校验状态码、响应头、甚至响应体内容（配合 Lua 可解析 JSON 中的 "status":"UP" 字段）
主动检查的关键配置与调优
在 upstream 块中为每个 server 添加 check 参数，典型配置如下：
- interval=3：每 3 秒探测一次；高频业务可缩至 1–2 秒，低频服务建议 5 秒以上，避免探测风暴
- rise=2 fall=3：连续 2 次成功才恢复上线，连续 3 次失败才下线；兼顾恢复及时性与抗网络抖动能力
- timeout=1：单次探测超时设为 1 秒，应略短于后端健康接口实际平均耗时（如后端通常 600ms 返回，则设 800ms 更稳妥）
- check_http_send "HEAD /health HTTP/1.1\r\nHost: api.example.com\r\n\r\n"：优先用 HEAD 方法，减少后端负担与网络开销
- check_http_expect_alive http_2xx http_3xx：避免把 302 重定向误判为异常
务必确保后端暴露真实、轻量、可靠的健康端点（如 /health 或 /actuator/health），禁止复用业务接口。
HTTPS 后端的健康检查实践
Nginx 开源版不支持带证书校验的 HTTPS 主动探测，但有成熟解法：
- 后端在 HTTPS 端口（如 443）上同时支持明文 HTTP 探针（如 ALPN 协商或 Go/Spring Boot 的兼容模式），Nginx 直接用 HTTP 方式探测
- 更稳妥的做法是后端额外监听一个非加密端口（如 8081），专用于健康检查，彻底规避 TLS 层干扰
- 无论是否启用主动探测，proxy_ssl_verify on 必须开启，并配置 proxy_ssl_trusted_certificate 指向后端 CA 根证书，确保业务流量安全可信
构建多层防护与可观测性
单一机制易失效，生产环境推荐三道防线叠加：
- 主动检查做日常巡检，负责秒级发现与隔离
- 保留 max_fails=2 fail_timeout=15s 被动策略作为兜底，捕获主动探针盲区（如 TLS 握手失败、长连接卡顿）
- 给探针请求加 X-Health-Probe 请求头，后端据此跳过鉴权、日志、限流，防止探针被拦截或压垮服务
- 配置 location /status { check_status; } 暴露健康状态页，供 Prometheus 抓取或人工核查
