公网环境无法直接用Keepalived实现VIP漂移，因云厂商禁用VRRP组播和ARP响应；可行方案是Keepalived仅做健康检测，通过云API驱动EIP切换，并关闭vrrp_strict、注释virtual_ipaddress等配置。
公网环境下用 Keepalived 做双机热备，核心难点不是 Keepalived 本身，而是 VIP 无法直接漂移——因为公有云（阿里云、腾讯云、AWS 等）普遍禁用 VRRP 组播（224.0.0.18）、禁止非绑定 IP 的 ARP 响应，且不允许用户随意配置虚拟网卡或发送伪造源 MAC 的报文。所以“照搬内网配置”必然失败。真正可行的方案，是绕过底层网络限制，用云平台能力兜底。
认清公网限制：VRRP 在云上基本不可用
Keepalived 默认依赖 VRRP 协议实现主备选举和 VIP 漂移，但在公有云中：
- 云厂商网络层拦截所有 VRRP 报文（协议号 112），advert_int、authentication、virtual_router_id 等配置全部失效
- VIP 必须是云平台分配的弹性公网 IP（EIP）或绑定在云服务器上的私网 IP，不能通过 ip addr add 临时添加
- 即使两台机器都显示 “MASTER”，VIP 也只会响应在其中一台上——因为云平台只允许一个实例持有该 EIP
替代方案：用云 API + Keepalived 状态驱动 EIP 切换
思路是让 Keepalived 不再负责“网络层漂移”，而是专注做健康判断，一旦确认主节点异常，就调用云平台 OpenAPI 将 EIP 从主切到备机。这是目前最稳定、被生产环境广泛验证的方式：
- 主节点 Keepalived 配置 state MASTER + priority 100，并启用 track_script 监控 Nginx 进程与端口（如 80/443）
- 编写切换脚本（如
/usr/local/bin/eip-failover.sh），使用云 CLI 工具（如 aliyuncli、tencentcloud-cli）执行 EIP 解绑/绑定操作 - 在
vrrp_script的fall和rise回调中触发该脚本，例如：fall "/usr/local/bin/eip-failover.sh switch-to-standby"rise "/usr/local/bin/eip-failover.sh switch-to-master" - 确保两台机器都已授权云 API 访问权限（RAM 角色或密钥），且目标 EIP 支持重绑定（部分云要求 EIP 与实例同地域、同可用区）
关键配置要点（以阿里云为例）
Keepalived 配置中需明确关闭对底层网络的依赖：
- 注释或删除
virtual_ipaddress块——VIP 由云平台托管，无需本地配置 - 设置
vrrp_strict为 关闭状态（即不写或加#vrrp_strict），否则会因缺少真实 VRRP 通信而拒绝启动 -
interface仍需填写实际网卡名（如 eth0），但仅用于日志和基础检测，不参与 VRRP 通信 -
mcast_src_ip可设为本机内网 IP，用于标识实例，不影响公网 EIP 切换逻辑
补充建议：增强可靠性与可观测性
公网环境故障定位难，必须前置加固：
- 健康检查脚本要覆盖多维度：Nginx 进程存活 +
curl -I http://127.0.0.1:80返回 200 + 关键 upstream 后端连通性 - EIP 切换脚本需加入幂等逻辑和重试机制（如失败后等待 5 秒再试 2 次），避免因云平台接口延迟导致重复操作
- 所有切换动作写入系统日志，并通过 syslog 或 webhook 推送到企业微信/钉钉，便于快速响应
- 备用节点同样部署完整服务栈（Nginx 配置、证书、静态资源），确保切换后功能 100% 一致
