Keepalived 通过可配置的 vrrp_script 调用外部健康检查脚本（如 nginx_check.sh），结合 HTTP 状态码、进程存活等多层验证动态调整节点优先级，实现 VIP 精准漂移。
Keepalived 对 Nginx 运行状态的主动监测，不是靠“猜”，而是通过可配置的健康检查脚本实现精准判断。它不依赖进程名是否存在这种简单方式，而是结合实际服务能力（如端口响应、HTTP 返回码、服务进程存活）做多层验证，确保 VIP 只漂移到真正能提供服务的节点上。
监测机制依赖自定义脚本
Keepalived 本身不内置 Nginx 健康检查逻辑，必须通过 vrrp_script 块调用外部 shell 脚本（如 /usr/local/src/nginx_check.sh）来完成。该脚本需明确返回 0（成功）或非 0（失败），Keepalived 根据返回值决定是否调整本节点优先级。
- 脚本通常执行
curl -I http://127.0.0.1:80/或kill -0 `cat /var/run/nginx.pid`等操作 - 建议检查 HTTP 状态码（如 200）、响应时间、甚至特定页面内容的 digest 值，避免仅检测端口通就认为服务正常
- 脚本需具备容错性：超时控制（
timeout 3s）、重试逻辑、日志记录便于排障
状态变化触发权重动态调整
脚本检测失败时，Keepalived 不会立即切换角色，而是按配置修改当前实例的优先级——这是主备切换的关键逻辑。
- 例如配置
weight -20，当脚本失败一次，本节点 VRRP 实例优先级就减去 20 - 若 MASTER 节点原 priority=100，检测失败后变为 80；而 BACKUP 节点 priority=90，则自动升为 MASTER
- 这种方式比直接 kill keepalived 进程更平滑，避免因瞬时抖动引发误切换
检查频率与失效判定需合理设置
太频繁会增加系统负载，太宽松则故障发现滞后。生产环境推荐组合使用：
-
interval 2：每 2 秒执行一次脚本 -
rise 2：连续 2 次成功才认为服务恢复 -
fall 3：连续 3 次失败才触发降权 - 搭配
advert_int 1（VRRP 心跳间隔 1 秒），整体故障感知延迟可控制在 3–5 秒内
注意 Nginx 自身状态与 Keepalived 协同
仅靠 Keepalived 监测不够，Nginx 配置也需配合：
- Nginx 必须监听
0.0.0.0:80（而非仅 127.0.0.1），否则本地 curl 通但外部无法访问仍属无效服务 - 建议启用
nginx -t在脚本中校验配置语法，防止 reload 后配置错误导致服务静默失败 - 若使用 systemd 管理 Nginx，脚本中可用
systemctl is-active --quiet nginx辅助判断
