必须编译安装nginx_upstream_check_module实现主动探活，配置check指令定义HTTP健康检查，搭配proxy_next_upstream重试机制与/status状态页提升可观测性。
轮询策略本身不带主动探测能力，必须通过扩展模块或组合配置实现真正的“未病先防”。原生 Nginx 的 max_fails/fail_timeout 属于被动检查，会拿真实用户请求当探针，必然导致部分 502。要保障高可用，得让 Nginx 主动发心跳、看状态码、测延时，再动态摘流。
启用 nginx_upstream_check_module（核心前提）
开源版 Nginx 默认不支持主动探活，必须编译安装第三方模块 nginx_upstream_check_module。Ubuntu/Debian 的 apt 包、CentOS 的 yum 包均不含此功能，需源码打补丁后重新编译。
- 下载模块源码（如 yaoweibin 版本），与 Nginx 源码合并后 configure 加上
--add-module=../nginx_upstream_check_module - 编译安装完成后，确认模块加载成功：
nginx -V 2>&1 | grep -o check应有输出 - 该模块是实现主动探活的工业级基础，不可跳过
在 upstream 中配置 HTTP 主动探活
模块启用后，在 upstream 块内添加 check 指令，定义探测频率、判定逻辑和健康接口路径。
-
check interval=5000 rise=2 fall=3 timeout=1000 type=http;：每 5 秒发一次 GET 请求；连续 2 次返回 200 才标记为健康，连续 3 次失败（超时或非 200）即下线 -
check_http_send "GET /health HTTP/1.0\r\n\r\n";：显式指定探测请求，避免默认行为差异 -
check_http_expect_alive http_2xx;：只把 HTTP 2xx 响应视为存活，4xx/5xx 全部算异常 - 后端服务需提供轻量级
/health接口，仅校验核心依赖（DB 连通、缓存可写等），响应快、无副作用
搭配 proxy_next_upstream 实现故障缓冲
即使有了主动探活，网络抖动或瞬时超时仍可能发生。需配合重试机制，避免单次失败直接报错给用户。
- 在
location块中设置：proxy_next_upstream error timeout http_502 http_503 http_504; - 加上
proxy_next_upstream_tries 2;和proxy_next_upstream_timeout 3s;，限制重试次数与时长 - 注意：不要盲目加
http_404，业务 404 是正常语义，不应触发重试 - 该配置与主动探活互补——前者应对偶发失败，后者保障节点长期可用性
暴露探活状态页便于可观测
模块提供内置状态页，可实时查看各节点探测结果、响应时间、失败计数等，是运维定位问题的关键入口。
- 在 server 块中添加：
location /status { check_status; } - 访问
http://your-nginx-ip/status即可看到表格化状态（IP、端口、状态、Rise/Fall、响应时间等） - 建议配合 Prometheus + nginx-vts-exporter 或自定义日志字段，将探测指标接入统一监控体系
- 状态页本身不暴露敏感信息，但应加 IP 白名单或 basic auth 保护
