Keepalived 配合 Nginx 实现接入层高可用，核心是通过 VRRP 协议动态管理同网段虚拟 IP（VIP），VIP 由 Keepalived 通过 ARP 广播宣告、不配置在网卡中；两节点需同二层网络，防火墙放行 VRRP（协议号112）和多播地址224.0.0.18；健康检查须用 HTTP 探针（如 curl 检查 200 OK），结合 vrrp_script 的 fall/rise 参数与 weight 降权机制触发 VIP 切换；主备靠 priority 值（如100 vs 90）而非启动顺序决定，virtual_router_id 和 auth_pass 必须一致；切换后需确保 Nginx 监听 0.0.0.0:80 而非仅 127.0.0.1。
Keepalived 配合 Nginx 实现接入层高可用，核心是用 VRRP 协议管理一个共享的虚拟 IP（VIP），让客户端始终访问这个 VIP，而 VIP 动态绑定在健康运行的 Nginx 节点上。当主 Nginx 故障时，Keepalived 自动将 VIP 漂移到备用节点，整个过程对用户无感。
虚拟 IP（VIP）是流量入口的关键
VIP 不属于任何物理网卡，而是由 Keepalived 通过 ARP 广播“宣告”自己持有该 IP。客户端只配置 VIP 作为服务地址，不感知后端实际是哪台机器在响应。两台 Nginx 服务器需在同一二层网络（如相同交换机、同网段），确保 VRRP 多播报文可达、ARP 刷新有效。
- VIP 必须与真实网卡 IP 在同一子网，例如真实 IP 是 192.168.1.10/24，VIP 就设为 192.168.1.100/24
- 不要将 VIP 配置在网卡配置文件中（如 ifcfg-ens33），它完全由 Keepalived 动态管理
- 防火墙需放行 VRRP 协议（协议号 112）和多播地址 224.0.0.18，否则心跳失败导致误切换
健康检查不能只看进程，要验证服务真实可用
仅检测 nginx 进程是否存活（如 killall -0 nginx）不够可靠——进程可能僵死、端口被占用但无法响应请求。推荐用 HTTP 探针模拟真实访问：
- 写一个检查脚本（如
/etc/keepalived/check_nginx.sh），用curl -s --head http://127.0.0.1 | grep "200 OK"判断首页是否返回成功 - 在 keepalived.conf 中定义
vrrp_script，设置interval 2（每 2 秒执行）、fall 3（连续 3 次失败才触发降权）、rise 2（连续 2 次成功才恢复） - 在
vrrp_instance中用track_script关联该检查，配合weight -30：一旦检查失败，当前节点优先级自动减 30，低于备机时立即触发 VIP 切换
主备角色与优先级必须严格区分
Keepalived 不靠“谁先启动”决定主备，而是比对 priority 值。MASTER 和 BACKUP 的配置几乎一致，仅三处不同：
-
state MASTERvsstate BACKUP—— 仅标识角色，不决定行为 -
priority 100（主） vspriority 90（备）—— 数值越大越优先持有 VIP -
virtual_router_id 51—— 主备必须完全相同，否则视为不同 VRRP 组，互不通信
注意：advert_int（心跳间隔）建议设为 1 秒；authentication 块中的 auth_pass 主备必须一致，否则认证失败导致无法同步状态。
切换后要确保 Nginx 真正接管流量
VIP 漂移只是第一步，还需确认新主节点上的 Nginx 正常工作：
- Nginx 必须监听
0.0.0.0:80（而非仅127.0.0.1:80），才能响应来自 VIP 的请求 - 检查
netstat -tlnp | grep :80，确认监听地址包含*:80或:::80 - 手动停掉主节点 Nginx 后，观察备节点是否在几秒内获得 VIP（
ip addr show查看）、且能 curl VIP 返回 200 - 避免使用
notify脚本重启 Nginx —— Keepalived 切换的是 VIP，不是服务本身；Nginx 应常驻运行，由健康检查兜底
