nginx后端节点剔除与恢复依赖被动检查与主动探测协同：被动检查靠请求触发，需proxy_next_upstream、max_fails和fail_timeout三者配合；主动探测需nginx_upstream_check_module，定时探活；参数须按业务特征调优，并辅以可观测性与告警闭环。
Nginx 本身不主动发心跳，后端节点的动态剔除与恢复不是“全自动发现”，而是靠配置组合触发的响应式机制：有流量时靠被动检查快速反应，无流量时靠主动探测提前干预，两者缺一不可。
被动检查：靠真实请求触发的自动剔除
这是开源 Nginx 开箱即用的能力，但必须三个参数协同生效：
-
proxy_next_upstream 必须显式启用，否则 502/503/504 等 HTTP 错误不会计入失败——推荐写全：
error timeout http_500 http_502 http_503 http_504 -
max_fails 和 fail_timeout 必须成对设置，例如
server 192.168.1.10:8080 max_fails=3 fail_timeout=30s：表示 30 秒内连续失败 3 次，该节点被标记为 down，持续 30 秒不参与调度 - 被标记为 down 的节点不会定时轮询，而是等下一个新请求到达时，Nginx 主动发一次试探请求；成功则立即恢复，失败则继续 down
主动检查：无流量时也能及时感知故障
被动检查在低峰期或冷启动阶段会失效（比如凌晨节点僵死但没请求打进来），此时需引入主动探测：
- 使用 nginx_upstream_check_module（OpenResty 已集成，原生 Nginx 需编译）
- 典型配置：
check interval=3 rise=2 fall=5 timeout=1 type=http uri=/health;→ 每 3 秒探一次，连续 2 次成功即恢复，连续 5 次失败才下线 - 后端必须提供轻量、稳定、低耗时的健康接口（如返回
{"status":"ok"}），避免用业务路径或慢接口做探针 - 配合
location /status { check_status; }可实时查看各节点状态
按业务特征调优失败阈值
同一套参数不适合所有服务，需结合响应行为差异化设置：
- 常规 Web 接口（用户中心、CMS）：
max_fails=3 fail_timeout=30s，兼顾抖动过滤与响应速度 - 高 QPS 网关（API 入口）：
max_fails=15 fail_timeout=10s，缩短窗口、提高容错，防毛刺误剔 - 慢响应服务（导出、上传）：
max_fails=2 fail_timeout=60s，避免单次长耗时被误判为失败 - 强一致链路（支付回调）：
max_fails=1 fail_timeout=10s，首次失败即隔离，降低风险
配套可观测性与告警闭环
Nginx 内部机制无法替代监控，必须补足外部观测能力：
- 仅靠
max_fails或check无法识别“假存活”（端口通但业务无响应），需日志 + 指标双校验 - 将 Nginx access log 中的 5xx、upstream_addr、upstream_response_time 接入 Prometheus 或 Zabbix
- 结合 Consul 或 etcd 实现服务注册与健康检查联动，可选方案包括：
— Consul-Template + reload（成熟稳定，适合中小规模）
— nginx-upsync-module（共享内存零 reload，适合容器化高频变更场景） - 告警不能只依赖 Nginx 日志，要基于监控平台对“连续 N 次健康检查失败”“下游可用率低于阈值”等复合条件触发短信/钉钉通知
