keepalived 通过外部脚本探测 nginx 状态并调整 vrrp 优先级以触发 vip 漂移；脚本需分层检查进程存活、http 健康端点返回码（200）、超时重试，并配置合理 interval/fall/rise/weight 参数，同时具备日志、容错及 notify 通知能力。
Keepalived 本身不直接管理 Nginx 进程，而是靠外部脚本探测其状态，并据此调整 VRRP 实例优先级，触发 VIP 漂移。脚本写得是否合理，直接决定故障能否被及时发现、服务能否快速恢复——不是“有没有脚本”，而是“脚本怎么写才靠谱”。
检查逻辑要分层：进程存在 ≠ 服务可用
只查 nginx 进程是否运行（如 ps -C nginx）远远不够。Nginx 可能卡住、worker 崩溃但 master 还在，或配置错误导致无法响应请求。真正有效的检查必须包含 HTTP 层验证。
- 第一层：确认 nginx 主进程存活（快速兜底）
- 第二层：用 curl 访问本地健康端点（如
/health或/index.html），校验返回码是否为 200 - 第三层（可选）：增加超时控制和重试机制，避免网络抖动误判
脚本执行参数要精准控制
Keepalived 调用脚本的频率、容忍失败次数、权重调整幅度，共同影响切换灵敏度与稳定性。默认配置容易导致“抖动切换”或“响应迟钝”。
-
interval 1是合理起点，但需结合业务容忍窗口调整；高并发场景建议设为 1～2 秒 -
fall 2表示连续失败 2 次才降权，避免单次超时就触发切换 -
rise 2表示连续成功 2 次才恢复权重，防止服务刚恢复就抢主 -
weight -2是常用值，确保失败后优先级低于备机，但不宜过大（如 -50），否则可能造成角色锁定
脚本自身要具备容错和日志能力
生产环境里，脚本出错或权限问题会导致 Keepalived 误判。没有日志的脚本等于黑盒，排查故障时无从下手。
- 脚本开头加
set -e或显式判断命令返回值，避免中间失败被忽略 - 所有关键步骤（curl 结果、重启动作、退出码）写入日志文件，例如
/var/log/keepalived/nginx_check.log - 使用绝对路径调用命令（如
/usr/bin/curl），避免 PATH 环境差异 - 检查 nginx 启动脚本路径是否一致（
/etc/init.d/nginx或/usr/sbin/nginx），CentOS 7+ 推荐用systemctl start nginx
配合 notify 脚本实现闭环反馈
仅靠 VIP 漂移还不够。运维人员需要知道“什么时候切了、为什么切、切到哪台”，才能快速介入或验证。
- 在 keepalived.conf 中配置
notify_master、notify_backup和notify_fault - notify.sh 脚本应记录时间戳、主机名、角色变化，并触发邮件或企业微信通知
- 可加入简单自检：切换后立即 curl 本机 VIP + 端口，确认服务已实际接管
