nginx负载均衡高可用必须依赖健康检查，开源版通过max_fails与fail_timeout实现被动检查，推荐使用nginx_upstream_check_module启用主动探测，并结合业务健康接口与响应体语义化校验确保真实可用。
Nginx 负载均衡集群要真正可靠，光把请求分发出去远远不够，关键得“知道后端还活着、还能干活”。健康检查不是可选项，而是高可用架构的底线——它让 Nginx 从被动转发者变成主动管理者。
原生配置实现基础健康感知
Nginx 开源版虽无 health_check 指令（该指令属 Plus 商业版），但可通过 max_fails 和 fail_timeout 组合，配合 proxy_next_upstream 实现基础级故障隔离：
-
max_fails=3表示在fail_timeout=10s时间窗口内，连续 3 次代理失败（如连接超时、5xx 响应）即标记该节点为不可用 -
proxy_next_upstream error timeout http_500 http_502 http_503 http_504让 Nginx 在遇到这些情况时自动重试其他节点 - 该方式属于“被动检查”，依赖真实业务请求触发，无法提前发现已宕机但端口仍通的“假活”节点
启用主动健康检查（推荐方案）
要真正实现“未病先防”，必须引入主动探测机制。最成熟开源路径是使用 nginx_upstream_check_module（常见于 OpenResty 或 Tengine 发行版）：
- 在
upstream块中添加检查指令：check interval=3 rise=2 fall=3 timeout=1 type=http;
表示每 3 秒探测一次，连续 2 次成功才恢复服务，连续 3 次失败则剔除 - 用
check_http_send发送定制请求，例如：check_http_send "GET /health HTTP/1.0\r\n\r\n"; - 用
check_http_expect_alive精确判断健康状态，如只接受http_2xx和http_3xx，避免将 404、503 等误判为正常
暴露可读的集群健康视图
运维和监控系统需要统一入口查看全局状态，建议配置一个专用 location 展示实时健康汇总：
- 通过
check_status指令（需模块支持）暴露 HTML 或 JSON 格式状态页，例如：location /status { check_status; } - 返回内容包含每个后端 IP、端口、当前状态（up/down）、失败次数、上次检查时间等字段
- 该页面可接入 Prometheus 抓取，或与告警平台联动，实现异常自动通知
结合业务状态页做语义化判断
健康 ≠ 端口通，更不等于进程在跑。真正的健康必须由应用自身定义：
- 要求后端提供标准健康接口，如 Spring Boot 的
/actuator/health、K8s 风格的/healthz，且响应体中明确包含"status":"UP" - 避免仅检查 HTTP 状态码，应解析响应体内容。必要时可用 OpenResty 的 Lua 脚本做深度校验
- 若后端依赖数据库或缓存，健康接口需同步探测下游依赖，否则 Nginx 认为“健康”的节点可能实际无法提供完整服务
