keepalived主备角色由state与priority共同决定；state backup配合preempt_delay更安全；virtual_router_id必须唯一且为1–255整数；健康检查脚本须返回0才视为正常。
Keepalived 配置文件里 vrrp_instance 的 state 值不能随便设
主备角色不是靠谁先启动决定的，而是由 state 配置项 + priority 共同锁定的。设成 BACKUP 却没配 preempt_delay，一重启就抢 VIP，下游连接直接断。
-
state MASTER表示“我默认就是主”，但实际是否真能持有 VIP，还要看priority是否最高、网络是否通、track_script是否通过 -
state BACKUP更安全，配合preempt_delay 30可避免脑裂或频繁切换；即使本机priority最高，也会等 30 秒再抢 - 两台都写
state MASTER？会同时发 VRRP 广播，交换机可能学习到两个 MAC 映射同一 IP，流量乱转
检查 virtual_ipaddress 是否生效，别只看 keepalived 进程在不在
进程 running ≠ VIP 已绑定。常见现象是日志里有 Registering IP address，但 ip addr show 看不到，或者 ping 不通 —— 很可能被内核参数拦住了。
- 确认网卡开启了
arp_ignore和arp_announce：sysctl net.ipv4.conf.all.arp_ignore应为1，net.ipv4.conf.all.arp_announce应为2 -
virtual_ipaddress必须写成192.168.1.100/24 dev eth0这种带掩码和设备的形式，漏掉/24或dev eth0，keepalived 会静默忽略该行 - 如果用的是云服务器（如阿里云、腾讯云），虚拟 IP 通常不支持——它们禁用了免费 ARP 和 VRRP 报文，配置再对也绑不上
健康检查脚本返回值写错，VIP 就永远卡在备机上
track_script 的退出码直接决定 keepalived 是否降级：必须是 0 表示健康，非 0（哪怕只是 1）就触发故障转移。很多人写完脚本没测退出码，结果服务明明正常，VIP 却飘走了。
- 脚本末尾加
exit 0显式收尾，别依赖最后一条命令的返回值（比如curl -f失败时返回非 0，但你后面又跟了echo ok，整个脚本退出码就变成 0 了） - 脚本里用
curl检查本地 Nginx，记得加-s -f -m 2：静默、失败报错、超时 2 秒，否则 hang 住会导致 keepalived 认为检查超时而反复重试 - 脚本路径要绝对路径，且 keepalived 启动用户（通常是 root）必须有执行权限；用
systemctl status keepalived看日志，搜索track_exec能看到真实调用命令和返回码
多实例共用一个 VIP？必须用 virtual_router_id 区分
同一个局域网里，所有 Keepalived 实例的 virtual_router_id 必须唯一。设成一样的，不同业务的 VRRP 包会互相干扰，出现 VIP 随机漂移、主备倒置、甚至两台同时 hold 住 IP。
-
virtual_router_id是个 1–255 的整数，不是字符串；10和"10"在配置里等价，但别写成010（八进制解析后变 8） - 不同业务线建议按用途编号：Web 层用
51，DB 代理层用52，避免后期扩容时撞 ID - 改完
virtual_router_id必须 reload（kill -USR1 $(cat /var/run/keepalived.pid)或systemctl reload keepalived），不能只改配置不触发重载，旧 ID 还在跑
真正麻烦的从来不是写几行配置，而是当三台机器、两个实例、一套健康检查混在一起时，virtual_router_id 写串了、track_script 权限没给、云厂商底层拦截了 VRRP —— 这些点不一个个敲实，VIP 看似飘得优雅，其实随时会断流。
