双机热备中“快速恢复”的核心是Keepalived+nginx协同机制：Keepalived通过VRRP协议管理VIP漂移，配合自定义健康检查脚本（检测Nginx进程与端口）实现进程级故障感知，主备节点严格配置state、priority（差值≥10）和virtual_router_id，辅以防火墙放行VRRP（协议号112）、SELinux策略调整及配置同步，确保故障时VIP秒级切换并端到端可用。
双机热备环境下，Nginx 本身不直接提供主备切换能力，真正实现“快速恢复”的核心是 Keepalived + Nginx 协同机制。故障发生时，恢复动作并非手动重启 Nginx，而是由 Keepalived 自动完成服务接管——前提是配置正确、检测可靠、状态同步及时。
Keepalived 心跳检测必须覆盖 Nginx 进程健康
仅靠 Keepalived 默认的 VRRP 协议检测网络层连通性远远不够。若 Nginx 进程已崩溃但 Keepalived 还在运行，虚拟 IP（VIP）仍停留在故障节点，用户请求将全部失败。
- 必须配置自定义健康检查脚本，定期探测 Nginx 工作进程和端口可用性
- 推荐脚本逻辑：用
systemctl is-active nginx或ps aux | grep -v grep | grep nginx确认 master+worker 进程存在；再用curl -s --connect-timeout 3 http://127.0.0.1/health（需提前在 Nginx 中配置 /health 路由返回 200）验证服务响应 - 脚本执行失败时，应主动触发 Keepalived 降低本机优先级（如
kill -USR2 $(cat /var/run/keepalived.pid)或通过vrrp_script机制自动降权）
主备角色切换必须依赖明确的优先级与状态同步
Keepalived 的 VRRP 实例需严格区分 MASTER/BACKUP 角色，且优先级差值足够大（建议 ≥ 10），避免因网络抖动引发脑裂或频繁切换。
- 主节点 keepalived.conf 中：
state MASTER，priority 100，virtual_router_id 51 - 备节点 keepalived.conf 中：
state BACKUP，priority 90，virtual_router_id 51（必须一致） - 确保两台机器的
interface名称一致（如 eth0 或 ens33），且 VIP 绑定成功后可通过ip addr show验证 - 启用
notify_master/notify_backup脚本，在角色变更时记录日志或触发告警
恢复后需验证全流程链路是否通畅
切换完成后不能仅确认 VIP 归属，必须模拟真实用户行为验证端到端可用性：
- 从客户端执行
curl -I http://[VIP]，检查 HTTP 状态码是否为 200，且响应头中Server字段显示当前活跃节点标识（如通过 Nginx 的add_header X-Node web01;区分） - 访问后端业务路径（如
/api/status），确认上游服务（Tomcat/PHP-FPM等）仍被正常代理 - 检查 Nginx error.log 和 access.log，确认无大量 502/504 错误，且日志时间戳连续无中断
- 用
tcpdump -i any host [VIP] and port 80抓包，验证请求确实到达新主节点并被响应
日常运维中要规避常见单点隐患
很多“恢复失败”其实源于部署阶段的疏漏，而非故障本身：
- 防火墙必须放行 VRRP 协议（协议号 112）及 VIP 的业务端口（如 80/443），CentOS7 上常用命令：
firewall-cmd --permanent --add-rich-rule='rule protocol value="112" accept' - SELinux 若开启，需允许 Keepalived 绑定 VIP：
setsebool -P keepalived_connect_any 1 - 两台 Nginx 配置文件必须完全一致（包括 upstream、proxy_set_header、SSL 设置等），建议用 rsync 或 Ansible 同步，避免人工遗漏
- 磁盘空间、文件描述符限制、OOM Killer 日志（
dmesg | grep -i "killed process"）需纳入日常巡检项，防止底层资源问题导致连锁宕机
