Nginx代理后端集群实现故障自动发现与剔除，需配置被动健康检查（proxy_next_upstream）或主动健康检查（nginx_upstream_check_module）；被动方式依赖请求失败触发，主动方式需编译模块并定时探测；建议结合状态页、监控告警及自动化工具形成可观测闭环。
要让 Nginx 代理后端集群时自动发现故障节点并剔除，核心在于合理配置 upstream 块中的健康检查机制。Nginx 开源版本身不支持主动周期性探针（如 HTTP GET 请求），但可通过 proxy_next_upstream 配合基础参数实现被动健康检查；若需主动探测，则需依赖 Nginx Plus 或第三方模块（如 nginx_upstream_check_module）。
使用 proxy_next_upstream 实现被动健康检测
这是开源 Nginx 最常用、无需额外编译的方式，原理是：当某台后端返回错误响应或超时时，Nginx 自动将请求转发给下一个 upstream 节点，并临时标记该节点为“不可用”一段时间。
-
必须启用
proxy_next_upstream，例如：proxy_next_upstream error timeout http_500 http_502 http_503 http_504; -
配合
fail_timeout和max_fails控制剔除逻辑：比如max_fails=3 fail_timeout=30s表示 30 秒内连续失败 3 次，该节点会被标记为不可用 30 秒 - 注意：该机制不主动发心跳，仅在真实请求失败时触发，因此故障发现有延迟，且低流量场景下可能长期无法感知节点宕机
通过 nginx_upstream_check_module 启用主动健康检查
这是一个广泛使用的开源补丁模块，可为 upstream 添加定时 TCP 或 HTTP 探活能力，适合对可用性要求较高的场景。
- 需重新编译 Nginx 并加载该模块（常见于 OpenResty 或手动打 patch 的构建版本）
- 配置示例：
upstream backend { server 192.168.1.10:8080; server 192.168.1.11:8080; check interval=3 rise=2 fall=5 timeout=1 fall=5 type=http; check_http_send "HEAD /health HTTP/1.0\r\n\r\n"; check_http_expect_alive http_2xx http_3xx; } - 其中
rise=2表示连续 2 次成功才恢复节点，fall=5表示连续 5 次失败才剔除，check_http_send定义探测请求，check_http_expect_alive定义判定健康的响应码
结合状态页与外部监控闭环管理
仅靠 Nginx 内部机制不够透明，建议暴露健康状态并接入外部系统，形成可观测闭环。
- 启用
upstream_check_status指令（来自同一模块），通过 location 暴露 JSON 或 HTML 格式的状态页，例如：location /status { check_status; } - 用 Prometheus +
nginx-vts-exporter或自定义 exporter 抓取指标，设置告警（如某节点持续 down 超过 2 分钟） - 配合 Ansible / Operator 等工具，在确认节点永久失效后自动更新 upstream 配置并 reload Nginx，避免“假死”节点长期占用连接槽位
注意事项与常见误区
健康检查看似简单，实际部署中容易踩坑：
- 不要忽略后端服务自身的健康接口设计：/health 端点应检查 DB 连接、缓存连通性等关键依赖，而非只返回 200
- 避免探测路径被业务防火墙或 WAF 拦截，建议使用独立 path（如 /nginx-health）并配置白名单
- fail_timeout 不宜设为 0，否则节点一旦失败就会永久剔除；也不宜过长（如设为 1h），会导致故障恢复滞后
- 多个 upstream 共享同一组后端时，各块的健康状态互不影响，需确保所有相关 upstream 都配置了统一的检查策略
