需结合主动探测、语义解析和数据闭环监控后端真实健康状态，推荐用nginx_upstream_check_module配置HTTP健康检查，并解析响应内容而非仅依赖状态码，同时暴露状态页接入Prometheus与告警体系。
不能只看后端节点“通不通”，得知道它能不能真正处理业务请求。Nginx 自带模块只能做被动响应式判断，必须结合主动探测、语义解析和数据闭环，才能监控到真实的健康指标。
用 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，不把 503、404 当健康
- 每个 server 行设 max_fails=0 fail_timeout=0，禁用原生被动机制干扰
- 加 default_down=true，防止 Nginx 启动时把未就绪节点当健康节点
让探测结果具备业务含义
返回状态码只是第一步，关键要验证响应内容是否反映真实运行状态：
- 后端应提供专用健康端点（如 /actuator/health 或 /readyz），内部检查 DB 连通性、线程池、磁盘空间等
- 若返回 JSON，例如 {"status":"UP","load":0.65,"mem_used_percent":72}，需配合 Lua 解析字段，而非仅依赖 HTTP 状态码
- 避免探测路径被 WAF 或防火墙拦截——将该路径加入白名单，或改用 type=tcp 检查端口连通性作为兜底
暴露状态页并接入统一监控体系
光有探测不够，得把结果可视化、可采集、可告警：
- 配置 location /status { check_status; allow 127.0.0.1; deny all; }，访问即可查看各节点 IP、up/down 状态、失败次数、最近响应码
- 用 nginx-module-vts 暴露 /status/format/json 接口，供 Prometheus 定时抓取
- 在 log_by_lua_block 中提取 $upstream_addr、$upstream_response_time、$upstream_status，打标后上报为直方图或计数器
- 定义 SLO 指标，例如“5 分钟内单节点错误率 >5%”触发告警，并与后端 JVM GC 时间、K8s Pod Ready 状态横向比对，确认根因
需要动态干预时选 OpenResty + Lua
当健康得分要直接影响路由决策，比如按负载自动降权或跳过高延迟节点：
- 用 lua-resty-upstream-healthcheck 模块解析 JSON 中的 load、memory_usage 等字段
- 将健康分写入 lua_shared_dict，再在 access_by_lua_block 中读取并动态调整权重
- 异常时调用 webhook 上报钉钉/企微，或写入 Redis 触发告警工作流
