Keepalived 不监控 Nginx 连接数，仅负责 VIP 高可用和四层负载均衡；Nginx 通过 least_conn 或 OpenResty+Lua 实现连接数导向的七层分发，外部系统可辅助采集指标并触发权重调整。
。它工作在四层（网络/传输层），核心能力是 VRRP 协议实现 VIP 高可用（主备切换），以及可选的 LVS 四层负载均衡。它**不具备七层应用层指标采集能力**，比如 Nginx 的活跃连接数、请求速率、响应时间等。 真正承担反向代理 + 七层负载均衡 + 健康检查 + 动态权重调整的是 **Nginx 自身**（通过 `upstream` 模块配合 `ngx_http_upstream_module` 和第三方模块）。 但你可以通过组合方案，**间接实现“连接数低的后端优先承接新流量”这一效果**。以下是实用、可落地的配置思路：
明确职责分工：谁管什么？
• Keepalived：只负责两个 Nginx 负载节点（lb01/lb02）之间的高可用——确保 VIP（如 192.168.10.200）始终落在健康的一台 Nginx 上，避免单点故障。
• Nginx：负责实际的反向代理、upstream 负载分发、后端健康检查，并可通过扩展方式感知后端压力（如连接数）。
• 外部脚本或监控系统（如 Prometheus + Exporter + Alertmanager）：采集后端真实服务器（web01/web02）的连接数、负载等指标，再触发 Nginx 配置热重载或 API 权重调整。
用 Nginx 原生能力实现连接数感知（推荐）
Nginx 官方模块不直接暴露“后端连接数”，但可通过以下方式逼近目标：
-
启用主动健康检查 + 自定义状态页：在每个后端 Web 服务（如 Nginx/Tomcat）上部署一个轻量接口（例如
/status/connections），返回当前活跃连接数（JSON 格式）。 -
用 Nginx
upstream_check_module（需编译）或第三方模块：定期调用该接口，将返回值作为健康状态依据；配合least_conn或自定义 Lua 脚本，动态调整 upstream server 权重。 -
更简单稳妥的做法：使用
least_conn调度算法：upstream backend { least_conn; server 192.168.100.20:80 max_fails=3 fail_timeout=30s; server 192.168.100.30:80 max_fails=3 fail_timeout=30s; }Nginx 内置的least_conn会自动把新请求发给当前活跃连接数最少的后端，无需外部干预，开箱即用。
进阶：用 OpenResty + Lua 实现连接数驱动的权重调度
如果你需要更精细控制（如按连接数线性降权、熔断高连接后端），可基于 OpenResty：
- 用 Lua 脚本定时
http.get()请求各后端的/status/connections接口； - 将结果缓存到 shared_dict；
- 在
balancer_by_lua_block中读取连接数，动态设置balancer.set_current_peer()目标； - 避免轮询高负载节点，实现真正的“连接数导向分发”。
为什么不要让 Keepalived 直接干这事？
• Keepalived 的 check_script 只能返回 0/非0 表示“存活/宕机”，无法传递数值型指标（如连接数=247）；
• 它没有内置 HTTP 客户端，不能调用后端状态接口；
• 修改 keepalived.conf 并 reload 会中断 VIP，影响整个集群可用性，不适合高频调整；
• 所有连接数逻辑放在 Nginx 层，更靠近流量路径，延迟更低、一致性更好。
不复杂但容易忽略：先用好 least_conn，再考虑 Lua 扩展。Keepalived 只管“谁来当老大”，Nginx 才管“怎么分发请求”。
