nginx原生支持被动健康检查，主动健康检查需依赖第三方模块nginx_upstream_check_module；该模块需源码编译安装，支持通过不同http探针路径（如/healthz与/actuator/health）区分静态与动态后端，并提供状态页、变量及日志监控能力。
在 Nginx 原生功能中，被动健康检查（如 proxy_next_upstream）是默认支持的，但主动式健康检查（定期向后端发送探测请求、实时更新节点状态）需要借助第三方模块。最常用、稳定且被广泛验证的是 nginx_upstream_check_module。
安装 nginx_upstream_check_module 模块
该模块不是官方内置模块，需在编译 Nginx 时手动添加：
- 从 GitHub 获取源码（如 yaoweibin 的分支）
- 确保使用与当前 Nginx 版本兼容的分支（例如 Nginx 1.20+ 推荐用
master或dev分支） - 重新编译 Nginx：
./configure --add-module=/path/to/nginx_upstream_check_module [其他原有参数]make && make install - 验证是否加载成功：
nginx -V 2>&1 | grep -o check应输出check
配置 upstream 主动健康检查（含动静态路径区分）
该模块支持为同一 upstream 设置不同检查方式，但不原生区分“动态”或“静态”后端**——需通过后端服务暴露的专用健康检查端点来实现逻辑区分。常见做法是：
- 静态资源服务（如 CDN 节点、静态文件服务器）提供轻量级
/healthz（返回 200 + 纯文本） - 动态应用服务（如 API 服务）提供带业务逻辑的
/actuator/health或/health?full=1（校验数据库连接等） - 在 upstream 中为不同用途的 server 指定各自的
check_http_send和check_http_expect_alive
示例配置：
upstream backend_api {
server 192.168.1.10:8000;
server 192.168.1.11:8000;
check interval=3 rise=2 fall=5 timeout=1 type=http;
check_http_send "GET /actuator/health HTTP/1.0\r\n\r\n";
check_http_expect_alive http_2xx http_3xx;
}
upstream backend_static {
server 192.168.1.20:8080;
server 192.168.1.21:8080;
check interval=2 rise=1 fall=3 timeout=1 type=http;
check_http_send "GET /healthz HTTP/1.0\r\n\r\n";
check_http_expect_alive http_2xx;
}
配合 Nginx 变量与状态页面实现精细化控制
模块提供变量（如 $upstream_addr、$upstream_status）和内置状态页，可用于监控与调试：
- 启用状态页：在 server 块中添加
location /status { check_status; }，访问/status可查看各 upstream 节点的检查结果、失败次数、状态（up/down） - 日志中记录健康检查结果：结合
log_format使用$upstream_addr和$upstream_response_time辅助排查 - 避免健康检查请求被业务规则误拦截：确保后端 Web 服务器（如 Nginx、Nginx Unit、Spring Boot）允许对
/healthz等路径不做鉴权、不限流
替代方案与注意事项
若无法重新编译 Nginx，可考虑以下替代路径：
- OpenResty + lua-resty-upstream-healthcheck：基于 Lua 实现，无需重编译，灵活性高，适合已有 OpenResty 环境
-
外部探活 + 动态配置 reload：用 Consul、etcd 或自研脚本定期探测，生成
upstream配置并触发nginx -s reload（注意 reload 频率与连接中断风险） - ⚠️ 注意：该模块不支持 HTTPS 健康检查（只发 HTTP 请求），若后端仅监听 HTTPS，需在后端反向代理层暴露 HTTP 健康端点，或改用 OpenResty 方案
