Keepalived主备切换是否生效取决于监控脚本返回值是否严格为0（健康）或非0（异常），必须显式exit、手动验证返回值，并与weight配置协同生效，同时排除脚本名、换行符、权限等干扰项。

Keepalived 主备切换是否生效，核心取决于监控脚本的返回值是否被正确识别和响应。返回值不是“看起来像对”，而是必须严格符合 Keepalived 的判定逻辑——它只认 0（健康/成功） 和 非0（异常/失败） 这两个信号，其余任何中间状态、日志输出、echo 内容或静默执行，都不会触发权重变化或角色迁移。

脚本返回值必须显式且唯一

很多问题源于脚本末尾没有明确 exit 语句，导致实际退出码依赖上一条命令的结果，极易被干扰。例如：

• 用 curl -I http://localhost:80 | grep "200 OK" 判断服务，但未加 set -e 或 || exit 1，即使匹配失败，脚本仍可能以 0 退出
• 脚本中调用了多个 redis 命令，但只在部分分支写了 exit 0 或 exit 1，其他路径默认返回上一命令的退出码，造成不确定性
• 使用 if [ $? -eq 0 ]; then ... fi 后未补全 else 分支并 exit，遗漏路径会返回上层 shell 的默认状态

建议所有监控脚本末尾统一用 exit 0 或 exit 1 显式收尾，不依赖隐式行为。

手动验证返回值比看日志更直接

别等故障发生才查，日常就该用 root 或 keepalived 实际运行用户身份测试：

• sudo -u keepalived /etc/keepalived/check_redis.sh
• echo $? —— 看输出是不是你预期的 0 或 1
• 再模拟异常：停掉 Redis，重复执行，确认返回值变为非0

如果返回值始终是 0，哪怕服务已挂，说明脚本逻辑没覆盖失败路径；如果始终是非0，可能是权限、路径、命令不存在等基础问题。

返回值要和 weight 配置协同生效

脚本返回 0 只代表“健康”，但能否影响 priority，还要看 weight 是否被正确加载并参与计算：

• vrrp_script 中 weight 必须带符号（如 weight -20 或 weight +10），否则 Keepalived 默认忽略
• track_script 必须在 vrrp_instance 块内正确定义，不能漏写或拼错名称
• 所有节点 state 建议统一设为 BACKUP，靠 priority + weight 动态升降，避免 MASTER 强制抢占引发脑裂

例如：主节点 priority 150，脚本健康时 weight +0，异常时 weight -30 → 实际 priority 变为 120，低于备节点的 130，从而触发切换。

常见干扰项必须提前排除

有些看似无关的细节，会直接让脚本“静默失败”：

• 脚本名含 keepalived 字样：grep 匹配会误计入自身进程，导致 ps | grep 类判断永远为真（如 check_keepalived.sh）
• Windows 编辑器保存的脚本：行尾是 \r\n，Linux 执行时报 /bin/bash^M: bad interpreter，实际根本没运行
• 缺少可执行权限：chmod +x /path/to/script.sh 不可省略
• shebang 错误：脚本写 #!/bin/bash 却用 /bin/sh 解释执行，某些语法（如 ==、数组）会报错