nginx需通过主动探测+状态解析+数据暴露三层实现真实健康监控：用nginx_upstream_check_module每3秒探活/health接口，仅认2xx为健康，禁用被动机制，暴露/status页并接入prometheus，辅以stub_status和proxy_next_upstream兜底。
Nginx 本身不内置实时健康监控能力，要真正掌握后端集群健康状况，得靠“主动探测 + 状态解析 + 数据暴露”三层配合。只看连接通不通、状态码是不是 200，很容易把“假活”节点当健康节点用。
用 nginx_upstream_check_module 做主动探活
这是最常用也最轻量的方案，需确认 Nginx 已编译该模块（运行 nginx -V | grep upstream_check 验证）。在 upstream 块中配置：
-
check interval=3 rise=2 fall=3 timeout=1 type=http：每 3 秒发一次探测请求 -
check_http_send "GET /health HTTP/1.1\r\nHost: api.example.com\r\nConnection: close\r\n\r\n"：发送真实业务级请求，避免用 HEAD -
check_http_expect_alive http_2xx：只把 2xx 当健康，明确排除 503、404 等临时或错误状态 - 每个
server行加max_fails=0 fail_timeout=0：禁用原生被动机制干扰 - 加
default_down=true：防止 Nginx 启动时把未就绪节点误判为健康
让探测结果反映真实业务能力
返回状态码只是起点，关键要看响应体是否符合预期：
- 后端应提供语义化健康接口（如
/actuator/health或/ready），响应体中包含status: UP、依赖项检查结果等字段 - 若需深度校验（比如判断
memory_usage > 95%就视为亚健康），可用 OpenResty +lua-resty-upstream-healthcheck模块解析 JSON 并动态降权 - 避免探测路径走主业务链路，单独暴露
/health，且确保该路径在防火墙、WAF 白名单中放行
暴露可采集的状态页并接入监控体系
光有探测不行，还得把结果可视化、可告警：
- 配置
location /status { check_status; allow 127.0.0.1; deny all; }，访问即可查看各节点 IP、up/down 状态、失败次数、最近响应码 - 接入 Prometheus：用
nginx-module-vts暴露/status/format/json，或用nginxlog-exporter解析自定义 access_log 中的$upstream_response_time和$upstream_status - 日志增强：在
log_format中加入$upstream_addr $upstream_response_time $upstream_status，便于按节点聚合 P95 延迟与错误率
补充兜底手段
- 对接
stub_status查看全局连接状态（Active connections、Waiting 数量），辅助判断是否出现连接堆积 - 设置
proxy_next_upstream error timeout http_500 http_502 http_503 http_504，作为被动 fallback，避免主动探测失效时完全失控
不复杂但容易忽略
