Keepalived双机热备关键在VRRP配置、健康检查绑定、网络层对齐三者严丝合缝：virtual_router_id必须一致，interface须匹配ip a结果，VIP与物理IP同子网；需配置nginx_check.sh等健康检查脚本并放行VRRP协议（IP号112），否则Nginx挂掉VIP仍滞留主节点导致502。
keepalived 实现双机热备，不是装上就自动高可用，关键在 VRRP 配置、健康检查绑定、网络层对齐三者必须严丝合缝。配错一个参数，比如 virtual_router_id 不一致或 interface 写错网卡名，VIP 就漂不起来；漏掉健康检查，Nginx 挂了但 VIP 还在主节点，用户直接 502。
确认网卡名和 VIP 网段是否真实可达
很多故障源于“以为能通，其实不通”：VIP 必须和两台服务器的物理 IP 在同一子网，且网卡名要完全匹配 ip a 输出结果（比如是 ens33 还是 eth0，CentOS 7/8/9 差异很大）。
- 先在两台机器上执行
ip -br a，确认目标网卡处于UP状态，且有同网段 IP（如192.168.100.11/24） - VIP（如
192.168.100.107）不能和任何物理 IP 冲突，也不能是网关或广播地址 - 防火墙必须放行 VRRP 协议：默认用组播地址
224.0.0.18+ UDP 端口112，命令示例：firewall-cmd --add-rich-rule='rule protocol value="vrrp" accept' - SELinux 若启用，需确保
setsebool -P keepalived_read_etc 1，否则keepalived读不到自定义检测脚本
state、priority 和 virtual_router_id 必须成对校验
vrrp_instance 块里这三个参数是主备识别的核心，任意一个不匹配，两台都会抢 VIP 或全退为 BACKUP。
-
state MASTER只能出现在主节点配置中；备节点必须写state BACKUP—— 写反了不会报错，但 VIP 死活不漂移 -
priority主节点建议设为100，备节点设为90（差值 ≥10 更稳妥），避免因短暂抖动触发误切换 -
virtual_router_id必须完全一致（范围 1–255），且同一局域网内不能重复——哪怕只配一个 VIP，ID 也得一样 - 如果启用了多实例（多个
vrrp_instance），每个实例的virtual_router_id必须不同，否则相互干扰
健康检查脚本必须返回正确 exit code 并可执行
靠 killall -0 nginx 或 curl -s http://127.0.0.1/health 判断服务状态是常见做法，但脚本本身容易出问题。
- 脚本路径必须和
vrrp_script中声明的完全一致（如/etc/keepalived/check_nginx.sh），且权限为755，属主为root - 脚本末尾必须用
exit 0表示健康，exit 1（或非 0）表示异常——返回其他值（如exit 2）会被keepalived忽略 - 不要在脚本里用
systemctl is-active nginx，因为keepalived子进程可能没加载 systemd 环境变量，改用pgrep -x nginx更可靠 -
interval建议设为2秒，太短增加负载，太长（如 >5s）会导致故障发现延迟，影响 SLA
切记：keepalived 不同步数据，只管 VIP 漂移
很多人以为配完 keepalived 就万事大吉，结果主库挂了，VIP 漂到备机，但备机数据库压根没数据——因为 keepalived 从不碰磁盘、不复制文件、不拉取 binlog。
- 它只做一件事：当检测到本地服务不可用时，降低自身优先级，让备节点升为 MASTER 并接管 VIP
- Nginx 静态页可以靠
rsync定时同步，MySQL/PostgreSQL 必须单独配置主从复制或流复制 - 若用
corosync + pacemaker管理数据库+VIP，则必须加colocation约束，否则 VIP 和数据库可能分处两台机器，服务仍不可用
真正跑稳双机热备，最常卡住的地方不是配置语法，而是网络层组播收发、健康检查脚本的静默失败、以及把「VIP 切换」等同于「服务自动恢复」这个认知偏差。
