Nginx 默认仅支持被动健康检查，通过 max_fails 和 fail_timeout 配合 proxy_next_upstream 实现后端故障自动剔除与恢复；需主动探测时可编译第三方模块 nginx_upstream_check_module。
Nginx 本身不内置主动式健康检测（如定期发请求探测后端是否存活），但可通过 被动检测 + 配置组合 实现可靠的后端健康状态管理。核心思路是：利用 upstream 模块的失败重试机制和状态标记，配合合理配置，让 Nginx 自动剔除异常节点，并在恢复后重新纳入服务。
启用 passive health check（被动健康检查）
这是 Nginx 官方支持的标准方式，依赖实际请求的响应结果判断后端状态：
- max_fails：在 fail_timeout 时间窗口内，允许后端连续失败的次数（默认为 1）。超过即标记为 down
- fail_timeout：定义“时间窗口”长度（如 10s），同时决定该 server 被标记为 down 的持续时间
- 只要请求返回 5xx 或超时/连接拒绝，就计入失败；成功响应（包括 2xx/3xx/4xx）不计失败
示例配置：
upstream backend {
server 192.168.1.10:8080 max_fails=3 fail_timeout=30s;
server 192.168.1.11:8080 max_fails=3 fail_timeout=30s;
}
配合 proxy_next_upstream 增强容错
让 Nginx 在遇到特定错误时自动转发到下一个上游服务器，避免单点失败影响整体可用性：
- proxy_next_upstream error timeout http_500 http_502 http_503 http_504：指定哪些条件触发重试
- 注意：默认不包含 4xx（如 404、403），除非业务明确需要重试
- 建议搭配 proxy_next_upstream_tries（最大重试次数）和 proxy_next_upstream_timeout（总重试超时）防雪崩
使用第三方模块实现主动健康检查（可选）
若需真正的主动探测（如定时发 HTTP HEAD 请求），可引入 nginx_upstream_check_module（需重新编译 Nginx）：
- 支持周期性 TCP 或 HTTP 探测，自定义 path、expected status、interval 等
- 探测失败后自动标记 down，恢复后自动 up，状态可通过 /status 页面查看
- 适用于对 SLA 要求高、后端无心跳接口、或需快速感知故障的场景
简单示例（启用后）：
upstream backend {
server 192.168.1.10:8080;
server 192.168.1.11:8080;
check interval=3 rise=2 fall=5 timeout=1 default_down=false;
}
补充建议：结合日志与监控闭环
仅靠 Nginx 内部机制不够直观，建议落地时配套：
- 开启 upstream 日志变量（如 $upstream_addr、$upstream_status），定位转发路径和响应码
- 用 Prometheus + nginx-vts-exporter 或 openresty 的 lua-resty-healthcheck 做可视化监控
- 对关键后端部署轻量级健康接口（如 /health），供主动探测或运维手动验证
不复杂但容易忽略。关键是理解 passive check 的触发逻辑和时间窗口设计，多数场景下已足够可靠。
