keepalived 通过 vrrp 协议在多台服务器间漂移 vip，支持单实例多 vip（同步切换）和多实例多 vip（独立控制），需配置 vrrp_instance、virtual_router_id、track_script 等实现精细化容灾与健康检查。
在 Nginx 高可用架构中，Keepalived 本身不直接管理 Nginx 的 VIP（虚拟 IP），而是通过 VRRP 协议在多台服务器间漂移 VIP。所谓“多 VIP 绑定策略”，实际是指在同一套 Keepalived 实例中，为不同业务或服务分配多个独立的虚拟 IP，并实现各自的主备切换逻辑——这需要合理配置 vrrp_instance 和 virtual_ipaddress 段，而非简单叠加 IP。
单实例多 VIP：共用同一优先级与状态切换
适用于多个 VIP 始终同步漂移（如对外提供统一入口的多个子域名或端口映射），所有 VIP 共享同一个 VRRP 实例的状态。此时只需在 同一个 vrrp_instance 下声明多个 virtual_ipaddress：
- 每个 VIP 可带掩码（如 192.168.10.100/24），也可省略，默认继承接口掩码
- 所有 VIP 在 MASTER 上同时绑定，在 BACKUP 上同时释放，切换原子性强
- 注意：若某 VIP 对应的服务在本地异常（如 Nginx 未启动），Keepalived 默认不感知，需配合 track_script 主动检测
多实例多 VIP：独立控制各 VIP 的主备行为
当不同 VIP 需要差异化容灾策略（例如 VIP-A 要求强主备，VIP-B 允许双主负载），应定义多个独立的 vrrp_instance，各自设置 state、priority、track_script 等：
- 每个 instance 必须有唯一 virtual_router_id（1–255），避免 VRRP 报文冲突
- 可为不同 VIP 设置不同 priority，甚至让一台机器在 instance A 中为 MASTER，在 instance B 中为 BACKUP
- 搭配 track_script 可实现“Nginx 健康则 VIP-A 漂移，Redis 异常则 VIP-B 不漂移”等细粒度控制
绑定策略关键细节
Keepalived 不绑定任何应用层服务，VIP 绑定完全由内核完成。真正影响“绑定效果”的是：
- 网卡匹配：virtual_ipaddress 中的 IP 必须能路由到 local interface（如 eth0），否则启动报错或无法 ARP 响应
- ARP 刷新：VIP 漂移后，需确保下游设备更新 ARP 表；可通过 nopreempt + notify 配合 arping 命令主动广播
- 防火墙放行：VRRP 使用协议号 112，iptables/nftables 需允许 INPUT/OUTPUT 方向的 VRRP 流量
- Nginx 监听适配：Nginx 配置中 listen 指令应绑定 0.0.0.0:80 或具体 VIP，避免只监听 localhost 导致 VIP 流量无法接入
验证与排障建议
部署后务必验证 VIP 实际归属和连通性：
- 在两节点分别执行
ip addr show，确认 VIP 出现在对应网卡下 - 用
tcpdump -i any vrrp观察 VRRP 报文是否正常收发 - 模拟故障（如 systemctl stop nginx）检查 track_script 是否触发 priority 降低并完成切换
- 从客户端 ping VIP 并 curl 测试，确认服务可达且无连接中断
不复杂但容易忽略。核心是理清 VIP 是网络层资源，Keepalived 是它的调度器，而 Nginx 只是运行在 VIP 之上的普通服务进程。策略设计取决于业务对一致性、隔离性和恢复速度的要求。
