企业级Nginx故障转移需确保“探测准、切得快、不误切、可恢复”：通过自定义健康检查脚本（监控进程+端口，2秒间隔、3次失败才降级）、显式配置ARP刷新、Nginx内部软故障兜底（proxy_next_upstream等），并用挂起进程、封端口、网络分区等真实场景压测验证。
企业级 Nginx 故障转移不是简单配两个节点加个 VIP 就完事，核心在于“探测准、切得快、不误切、可恢复”。真正落地时，单靠 Keepalived 默认配置容易踩坑——比如脑裂、VIP 漂不走、服务已死但检测没触发。下面从四个关键环节讲清楚怎么配才稳。
一、Keepalived 心跳与故障判定要够细
默认的 VRRP 心跳（advert_int 1）只管网络通不通，但 Nginx 进程假死、CPU 打满、连接队列塞满等情况它完全感知不到。必须叠加自定义健康检查脚本：
- 用 track_script 监控 Nginx 主进程是否存在，同时检查 80/443 端口是否可连（避免进程在但端口未监听）
- 脚本执行间隔设为 2 秒，连续失败 3 次 才触发降级，防止瞬时抖动误判
- 主备节点的 priority 差值建议 ≥ 50，避免因时间不同步或网络延迟导致双主
二、VIP 漂移后必须强制刷新局域网 ARP
VIP 切到备节点后，交换机和客户端本地 ARP 缓存可能还指向旧 MAC 地址，造成几分钟内请求丢包。不能只依赖 Keepalived 自发的免费 ARP：
- 在 keepalived.conf 的 vrrp_instance 块里显式添加：notify_master "/path/to/arp-refresh.sh"
- 脚本内容只需一行：arping -c 3 -A -I eth0 10.0.0.100（替换为你的 VIP）
- 确保服务器关闭了内核参数 arp_ignore 和 arp_announce 的限制，否则 arping 可能无效
三、Nginx 本身要做“软故障兜底”
Keepalived 负责机器级切换，但 Nginx 内部也要防止单点崩溃扩散：
- upstream 配置中启用 proxy_next_upstream error timeout http_500 http_502 http_503 http_504，让单个后端异常不阻断整条链路
- 设置 proxy_next_upstream_tries 3 和 proxy_next_upstream_timeout 5s，控制重试边界
- 对关键 upstream 加 max_fails=3 fail_timeout=30s，避免反复试探已宕机的服务
四、验证和压测不能只看“切成功”，要看“切得稳”
上线前必须模拟真实故障场景，而非仅 systemctl stop nginx：
- 用 kill -STOP $(cat /var/run/nginx.pid) 挂起进程（模拟假死），验证脚本能捕获
- 用 iptables -A INPUT -p tcp --dport 80 -j DROP 封禁端口（模拟端口不可达），确认 VIP 是否漂移
- 用 ab 或 wrk 对 VIP 发起持续请求，人为制造主节点网络分区（如拔网线），观察切换耗时是否 ≤ 3 秒、有无请求丢失
