要实现基于业务接口的主动健康检查，需使用ngx_http_upstream_check_module模块，在upstream中配置check指令（type=http），自定义check_http_send请求并结合check_http_expect_alive及响应体校验，最后通过/location /status暴露状态页。
要实现基于业务接口的主动健康检查，核心是让 Nginx 定期向后端真实业务路径（如 /health 或 /actuator/health）发起探测，并依据响应内容而非仅连接通断来判断服务是否真正就绪。开源 Nginx 本身不支持该能力，需依赖第三方模块 ngx_http_upstream_check_module（Tengine 或手动编译集成版），它支持 HTTP 类型检查并可自定义请求与响应匹配规则。
启用 check 指令并指定 HTTP 探测类型
在 upstream 块中添加 check 指令，并显式设置 type=http，否则默认可能为 tcp。同时建议关闭默认的被动机制干扰（如移除 max_fails 和 fail_timeout），避免逻辑冲突：
check interval=3 rise=2 fall=3 timeout=1 type=http;-
interval=3：每 3 秒探测一次，兼顾时效与压力 -
rise=2：连续 2 次成功才恢复上线，防误恢复 -
fall=3：连续 3 次失败才下线，容忍偶发抖动 -
timeout=1：单次探测超时设为 1 秒，避免阻塞检查周期
发送符合业务要求的探测请求
使用 check_http_send 发送带路径、协议版本和必要头的轻量请求，确保命中真实健康接口：
check_http_send "GET /health HTTP/1.1\r\nHost: example.com\r\nConnection: close\r\n\r\n";- 推荐用
GET而非HEAD，便于后端返回结构化状态（如 JSON） - 显式指定
Host头，适配虚拟主机或网关路由场景 - 避免使用
keep-alive（除非后端明确支持复用），简化连接管理
按业务响应体精准判定健康状态
仅靠状态码（如 200）不够可靠——某些服务即使异常仍返回 200。应结合响应体内容校验：
-
check_http_expect_alive http_2xx;保留基础状态码要求 - 配合
check_http_send中的请求路径，让后端返回类似{"status":"UP","checks":{...}}的 JSON - 若需更严格匹配（如必须含
"status":"UP"且"diskSpace":"UP"），需修改模块源码或升级至 Nginx Plus 使用match块
暴露健康状态页面用于人工核验与监控对接
配置专用 location 提供可视化节点状态，便于排查和 Prometheus 等工具采集：
location /status { check_status; access_log off; allow 127.0.0.1; deny all; }- 返回结果含每个 server 的 IP、端口、当前状态（up/down）、失败次数、最近检测时间
- 建议限制访问来源，避免敏感信息泄露
