需启用nginx_upstream_check_module主动健康检查并配置proxy_next_upstream兜底：check interval=2 fall=3 rise=2 timeout=1 type=http，配合/health轻量探测与http_502/503/504重试，实现秒级无损剔除。
要实现生产环境中后端节点故障的秒级无损剔除，仅靠 Nginx 开源版默认的被动检查远远不够。必须引入有状态的主动健康检查——即独立于真实业务请求、周期性探测、带状态记忆与平滑上下线逻辑的机制。核心在于：用第三方模块 nginx_upstream_check_module 搭配精细参数调优，并与 proxy_next_upstream 协同兜底。
启用 nginx_upstream_check_module 主动探测
该模块是开源生态中最成熟、生产验证最充分的方案，支持 HTTP/TCP/SSL 等多种探测类型，且状态独立维护，不依赖流量触发。
- 编译安装时需显式添加：
--add-module=/path/to/nginx_upstream_check_module - 在
upstream块中启用检查，例如：
upstream app_cluster {
server 192.168.10.10:8000;
server 192.168.10.11:8000;
check interval=2 rise=2 fall=3 timeout=1 type=http;
check_http_send "HEAD /health HTTP/1.1\r\nHost: localhost\r\n\r\n";
check_http_expect_alive http_2xx;
}
-
interval=2：每 2 秒探测一次，满足“秒级”响应要求 -
fall=3：连续 3 次失败即标记为down（约 6 秒内完成故障识别） -
rise=2：连续 2 次成功即恢复为up，避免恢复延迟 -
timeout=1：单次探测严格控制在 1 秒内超时，防止卡住检查线程 - 务必使用轻量
HEAD请求 + 后端专用/health接口，避免干扰业务或压垮服务
配置 proxy_next_upstream 实现请求级容错兜底
主动检查再快，也存在探测间隙（如刚探测完就宕机）。此时需靠真实请求失败触发快速重试，确保单个用户请求不因节点瞬时失联而报错。
- 在
location中启用并明确错误类型：
location /api/ {
proxy_pass http://app_cluster;
proxy_next_upstream error timeout http_500 http_502 http_503 http_504;
proxy_next_upstream_tries 2;
proxy_next_upstream_timeout 5s;
}
- 关键点：必须包含
http_502/503/504—— 否则后端返回网关错误不会触发重试，max_fails也不会累加 -
proxy_next_upstream_tries 2表示最多尝试 2 个节点（含首试），避免链式重试放大延迟 -
proxy_next_upstream_timeout 5s是整个重试过程总耗时上限，保障用户体验
规避常见误判与状态漂移
秒级剔除若缺乏防护，极易因网络抖动、GC 暂停或慢接口导致节点被反复踢入踢出，引发雪崩。
- 后端
/health接口必须只校验核心依赖（如 DB 连通性、本地缓存可写），不查下游微服务或耗时计算 - 禁止在
upstream中对同一节点同时设置max_fails和check—— 二者状态逻辑冲突，以check为准，max_fails可省略 - 通过
location /status暴露check_status页面，实时观察各节点当前状态（up/down）、失败计数、最后检测时间，便于快速定位误判 - 若后端启用了连接池或长连接，需确保其健康接口能反映真实服务能力（例如拒绝新连接时，
/health应返回 503）
生产建议：组合使用 + 监控闭环
真正的“无损”，不只是 Nginx 层面的剔除，更是可观测、可验证、可回滚的闭环。
- 将
check_status页面接入 Prometheus（通过 exporter 或自定义 metrics 抓取），对down节点数、平均探测延迟、失败率设告警 - 配合后端日志埋点，在
/health返回非 2xx 时记录原因（如 “DB timeout”, “cache full”），辅助根因分析 - 灰度发布时，先将新节点设为
backup，待check稳定通过后再移除backup标记，避免上线即故障 - 不建议在高并发核心链路中使用
type=tcp检查——它只能确认端口可达，无法判断应用是否真正在处理请求
