Nginx可通过nginx_upstream_check_module实现毫秒级主动健康探测，需配置/health端点、HEAD方法、shared memory统一状态，并辅以max_fails被动防护及X-Health-Probe请求头等三道防线。
用 nginx_upstream_check_module 做轻量 HTTP 主动探针
这是开源 Nginx 下最成熟、压测验证过的高性能方案，已被 Tengine 和多数 OpenResty 发行版集成。它复用 Nginx 原生事件循环（epoll/kqueue），每个 worker 独立发起非阻塞 HTTP 探测，不额外启线程，CPU 占用稳定在 1% 以内。
- 后端必须暴露 /health 端点，返回 200 且响应体极小（建议纯文本或空 body）
- 配置示例中 timeout=1 表示探针超时仅 1 秒，避免卡住整个探测周期
- interval=3 是最小安全间隔；低于 2 秒易引发探测风暴，尤其多 worker 场景
- 使用 HEAD 方法而非 GET，省去响应体传输，降低网络和后端解析压力
规避 per-worker 状态不一致问题
默认每个 worker 维护独立健康状态，可能导致同一后端在不同 worker 视角下“忽上忽下”。这不是 bug，而是设计取舍。
- 启用 shared memory zone（需模块支持）统一存储各节点状态，OpenResty 中可用 lua_shared_dict 模拟
- 若无法改模块，可将 fail 阈值设高些（如 fall=5），靠统计平滑抖动，比强行同步更稳
- 禁用 backup 节点的主动检查，只让它兜底——避免健康流量误切到冷备节点引发雪崩
用 max_fails + fail_timeout 做兜底被动防护
即使开了主动探测，也要保留被动机制。它不依赖探针，而是从真实请求失败中学习，对“假活”（进程在、接口卡死）更敏感。
- 设置 max_fails=2 fail_timeout=15s，比主动探测更激进一点，形成双保险
- 注意：该参数作用于 单次请求失败，不是探针失败；所以它能捕获 TLS 握手失败、长连接卡顿等主动探测盲区
- 不要把 fail_timeout 设成 60s 以上，否则恢复太慢；也不要低于 10s，防止瞬时抖动误杀
生产环境必须加的三道防线
高性能不止看探测快，更要看稳、准、可观察。
- 给探针加 X-Health-Probe: true 请求头，后端据此跳过鉴权/日志/限流，避免探针被当成攻击流量拦截
- 暴露 /status 接口（需启用 stub_status + check 模块），用 Prometheus 抓取节点 up/down 状态、失败率、响应时间分位数
- 后端 /health 返回 JSON 时，务必限制字段数和总长度（建议 ≤200 字节），避免 Nginx 解析耗时飙升
