track_script脚本必须返回0（健康）或非0（不健康），仅依赖退出码，不解析输出；必须设超时（如timeout 3s curl）、用绝对路径、chmod +x，并配置interval/fall/weight协同生效。
track_script 脚本必须返回 0 或非 0，且不能超时
Keepalived 的 track_script 本质是周期性执行 shell 脚本并读取其退出码：0 表示“健康”，非 0（如 1、2）表示“不健康”。它**不解析 stdout/stderr**，只看 $?。常见错误是脚本里用了 echo 就以为 Keepalived 能“看到状态”，其实完全没用。
更关键的是超时控制：Keepalived 默认等待脚本最多 2 秒（由 rise/fall 间隔隐式约束），若脚本卡住或未设超时，会导致主备切换延迟甚至假故障。必须显式加 timeout。
- 用
timeout 2s curl -sf http://127.0.0.1:8080/health || exit 1，别裸写curl - 避免调用可能阻塞的命令：如无
-w的ping、未设read超时的nc - 脚本开头加
set -e确保任意命令失败即退出，防止逻辑跳过检查
HTTP 探活要校验响应体内容，不只是状态码
仅靠 curl -I 检查 200 是危险的——后端进程僵死但反向代理（如 Nginx）仍可能返回 200。真实场景中，必须验证响应体是否含预期标识，比如 "status":"up"。
示例脚本片段（保存为 /etc/keepalived/check_api.sh）：
#!/bin/bash set -e response=$(timeout 3s curl -sf -m 3 http://127.0.0.1:8080/health 2>/dev/null) if [[ "$response" =~ \"status\"\:\"up\" ]]; then exit 0 else exit 1 fi
- 用
-m 3和timeout 3s双重保险防 hang - 正则匹配比
grep -q更可靠（避免空响应误判为成功） - 不要依赖
curl -f：它只管 HTTP 状态码，4xx/5xx 才非 0，而 200+ 错误 JSON 仍返回 0
Keepalived 配置里 track_script 的 interval 和 weight 要对齐业务容忍度
track_script 块里的 interval 决定探测频率，但真正影响 VIP 切换的是 vrrp_instance 中的 track_script 引用方式——尤其是 weight 设置。很多人忽略这点，导致健康检查失效。
例如：
vrrp_script chk_api {
script "/etc/keepalived/check_api.sh"
interval 2
fall 3
rise 2
}
vrrp_instance VI_1 {
...
track_script {
chk_api weight -5
}
}
-
fall 3表示连续 3 次失败才触发降权，不是“失败一次就切” -
weight -5是相对值，需确保主节点原始priority比备节点高至少 6，否则一次失败就可能让备机 priority 反超 - 若业务要求 5 秒内发现故障，
interval 2+fall 3最坏需 6 秒，此时应改用interval 1+fall 5或调整 weight 幅度
脚本权限、路径和 SELinux 容易被忽略
Keepalived 主进程通常以 root 运行，但子进程执行脚本时可能受限于环境变量、PATH 或安全策略。
- 脚本必须有可执行权限：
chmod +x /etc/keepalived/check_api.sh - 脚本内所有命令用绝对路径：
/usr/bin/curl而非curl（Keepalived 不继承 shell PATH） - SELinux 启用时，
keepalived_t域默认禁止执行网络请求，需打补丁：ausearch -m avc -ts recent | audit2allow -M keepalived_net && semodule -i keepalived_net.pp，或临时用setsebool -P keepalived_connect_any on - 测试时用
sudo -u root /etc/keepalived/check_api.sh模拟实际执行环境，别只在自己用户下跑通就认为 OK
tail -f /var/log/messages | grep Keepalived 观察日志里 “VRRP_Script(chk_api) failed” 和 “Got advertisement…” 的时间差，这是唯一能验证配置是否生效的依据。
