应配置主动+被动健康检查：被动检查用max_fails=2 fail_timeout=15s与proxy_next_upstream配合；主动探针需启用nginx_upstream_check_module，每3秒请求/health接口并校验2xx响应，且后端需同步验证数据库、redis等依赖并跳过鉴权。
要保障后端 Node 服务在 Nginx 负载均衡下的真实可用性，不能只依赖端口通不通，必须配置能反映业务状态的健康检查探针。开源 Nginx 本身不带主动探测能力，需结合被动机制与第三方模块（如 nginx_upstream_check_module）实现可靠判断。
用被动检查兜底真实请求失败
这是 Nginx 原生支持的方式，无需编译额外模块，靠实际转发请求中的异常来标记节点。
- 在
upstream的每个server行里设置max_fails=2 fail_timeout=15s：连续 2 次请求失败（如超时、502/503/504），就暂停向该 Node 发流量 15 秒 - 必须配合
proxy_next_upstream error timeout http_500 http_502 http_503 http_504，否则即使后端挂了，Nginx 也不会自动切走 - 对 Node.js 应用特别有用——比如进程卡在 GC 或事件循环阻塞，端口仍通但响应极慢，被动检查能从真实超时中感知到
用主动探针识别“假死”节点
仅靠被动检查发现故障太慢（通常要等用户请求触发），主动探针可每几秒发一次轻量请求，提前摘除问题节点。
- 确认 Nginx 已编译
nginx_upstream_check_module（运行nginx -V | grep upstream_check查看） - 在
upstream块中添加：check interval=3 rise=2 fall=5 timeout=1 type=http;check_http_send "GET /health HTTP/1.1\r\nHost: your-api.com\r\nConnection: close\r\n\r\n";check_http_expect_alive http_2xx; - Node 服务需暴露
/health接口，返回 200 且响应体尽量小（建议纯文本或空 body），避免 JSON 解析开销 - 禁用
max_fails（设为max_fails=0 fail_timeout=0），避免被动与主动机制互相干扰
让探针真正反映 Node 业务就绪状态
很多团队只返回 200 就算健康，但 Node 进程活着 ≠ 服务可用。探针应验证关键依赖是否就绪。
- 在 Express/Koa 等框架中，
/health接口应同步检查数据库连接池、Redis 连通性、内部队列长度等，任一失败即返回非 2xx - 加请求头标识探针流量：
X-Health-Probe: true，后端据此跳过鉴权、日志记录和限流，防止探针被当成攻击拦截 - 避免使用
GET /或GET /ping这类静态路径——它们不经过业务中间件，无法反映真实负载能力
规避常见干扰因素
防火墙、WAF、Node 启动延迟都可能让探针误判，需针对性调参。
- 若 Node 启动慢（如首次加载大量模块），设
default_down=true，避免 Nginx 启动时把未就绪节点当健康节点用 - 遇到安全组拦截
/health，改用type=tcp做端口连通性检查，或统一放行/healthz这类更通用的路径 - 多 worker 场景下，各 worker 默认独立维护健康状态，易出现“同一节点在不同 worker 视角下状态不一致”。可提高
fall值（如fall=5）平滑抖动，比强行同步更稳定
