Nginx开源版不内置健康检查,需通过nginx-plus、OpenResty+lua-resty-upstream-healthcheck、nginx_upstream_check_module或外部服务动态配置实现;所有方案均需后端提供低开销健康接口并配合proxy_next_upstream使用。

Nginx 开源版(官方主线版本)本身不内置健康检查模块,其 upstream 的轮询(round-robin)是静态的:只要后端地址在配置中,就参与调度,即使已宕机也不会自动剔除。要实现带主动健康检查的轮询负载均衡,需借助第三方模块或升级到商业版。
使用 nginx-plus(官方商业版)
nginx-plus 原生支持主动健康检查,配置简洁可靠:
- 在
upstream块中启用health_check指令,可指定间隔、失败阈值、HTTP 状态码等 - 支持 TCP、HTTP、HTTPS 多种探测方式
- 配合
match块可自定义响应体校验逻辑
示例:
upstream backend {
server 192.168.1.10:8080;
server 192.168.1.11:8080;
health_check interval=3 fails=2 passes=2 uri=/health;
}使用 openresty + lua-resty-upstream-healthcheck
OpenResty 是基于 Nginx 的扩展平台,通过 Lua 模块可实现灵活的健康检查:
-
lua-resty-upstream-healthcheck支持异步探测、权重动态调整、自定义探针逻辑 - 需在
init_worker_by_lua_block中初始化检查器,在balancer_by_lua_block中做路由决策 - 适合需要细粒度控制(如按响应时间加权、故障隔离策略)的场景
使用 nginx_upstream_check_module(第三方补丁模块)
这是最常用的开源方案,需重新编译 Nginx:
- 为
upstream添加check指令,支持 TCP/HTTP 检查、间隔、超时、失败次数等参数 - 提供状态页(如
/status)查看节点实时健康状态 - 注意:该模块不维护于主线,需确认兼容你使用的 Nginx 版本(如适配 1.20+ 需用 fork 维护版)
示例:
upstream backend {
server 192.168.1.10:8080;
server 192.168.1.11:8080;
check interval=3 rise=2 fall=5 timeout=1 type=http;
check_http_send "HEAD /health HTTP/1.0\r\n\r\n";
check_http_expect_alive http_2xx http_3xx;
}替代思路:依赖外部服务 + 动态配置
若无法重编译或引入 Lua,可用轻量级方案:
- 用 Consul、etcd 或自建脚本定期探测后端,将健康节点列表写入 Nginx 可读的配置文件(如 JSON 或 conf 片段)
- 通过
include引入,并配合nginx -s reload或openresty -s reload生效 - 注意 reload 频率和连接中断问题,建议搭配平滑 reload 工具(如
nginx-updater)
不复杂但容易忽略:无论选哪种方式,健康检查路径(如 /health)必须由后端真实提供且低开销;同时应配置 proxy_next_upstream 实现请求级失败重试,与节点级健康检查形成双重保障。











