Keepalived 通过自定义 vrrp_script 脚本实现 API 业务级健康检查，脚本返回 0（健康）或非 0（异常），结合 weight、fall/rise 规则触发主备切换；需确保检查地址为真实服务端点、避免 DNS 依赖、验证下游依赖，并通过日志和 VIP 迁移验证秒级切换效果。
Keepalived 本身不直接解析 HTTP 响应体或校验 API 返回内容，但它支持通过自定义脚本（vrrp_script）执行任意健康检查逻辑，从而实现对后端业务 API 的精准状态监控和切换控制。关键在于把“API 是否可用”转化为一个明确的退出码（0 表示健康，非 0 表示异常），再由 Keepalived 根据该结果触发 VRRP 状态变更。
配置自定义 API 检查脚本
在两台 Keepalived 节点上创建可执行脚本，用于调用目标 API 并判断其业务级可用性：
- 脚本路径建议统一为
/etc/keepalived/check-api.sh - 需赋予执行权限：
chmod +x /etc/keepalived/check-api.sh - 脚本应包含超时控制、HTTP 状态码校验、响应内容关键字匹配（如
"status":"ok"）、甚至 JSON 字段解析（可用jq工具） - 示例逻辑：使用
curl -s --max-time 3 http://127.0.0.1:8080/health | jq -e '.status == "up"' > /dev/null，成功则返回 0，失败返回 1
在 keepalived.conf 中集成脚本检测
在 vrrp_instance 块中引用该脚本，并设置检查频率与权重影响规则：
- 在
global_defs或全局区域外定义脚本块：vrrp_script chk_api {<br> script "/etc/keepalived/check-api.sh"<br> interval 5<br> weight -5<br> fall 3<br> rise 2<br>} -
interval 5表示每 5 秒执行一次检查 -
fall 3表示连续 3 次失败才判定为故障；rise 2表示连续 2 次成功才恢复为健康 -
weight -5表示该检查失败会使当前节点优先级降低 5，若降后低于备节点，则自动触发主备切换 - 在
vrrp_instance VI_1内添加track_script { chk_api }
确保检查目标与真实服务一致
避免误判，需注意以下几点：
- 脚本中访问的 API 地址必须是本机实际承载的服务（如 HAProxy/Nginx 后端的真实 upstream 或本地 health 端点），不能只检查进程是否存在
- 若 API 依赖数据库或缓存，应在 health 接口中一并验证这些下游组件，否则可能“接口通但业务不可用”
- 不要在脚本中使用
localhost，而应使用127.0.0.1或具体监听地址，防止因 DNS 解析延迟或失败导致误报 - Keepalived 进程运行用户需有执行
curl、jq等命令的权限，必要时在脚本开头指定完整路径（如/usr/bin/curl）
验证与日志观察
完成配置后，重启 Keepalived 并主动模拟 API 异常来测试切换效果：
- 手动停掉后端服务或修改 health 接口返回错误响应，观察
ip a是否发生 VIP 迁移 - 查看 Keepalived 日志：
journalctl -u keepalived -f，关注chk_api执行结果及Entering FAULT STATE、Transition to MASTER STATE等关键事件 - 确认切换时间在秒级（通常 3×5=15 秒内完成），符合业务 RTO 要求
