keepalived vip漂移仅完成网络层切换，不等于服务就绪；需验证nginx进程、配置加载、upstream健康状态及备机真实承载能力，避免因容量不足或状态不同步导致“假切换”压垮备用机。
备用机在故障转移中被压垮，本质不是“切换成功了”，而是“切换失败了”——流量瞬间全量涌向一台原本只承担低负载的机器，暴露的是容量规划与状态协同的双重断点。排查需从流量入口、节点状态、资源瓶颈三线并进。
确认故障转移是否真正完成
Keepalived 的 VIP 漂移只是网络层动作，不等于服务已就绪。常见假切换：
- VIP 已漂到备机，但 Nginx 进程未启动、配置加载失败或 worker 未真正响应请求（用 curl -I http://VIP/health 检查返回码和响应时间，不能只看端口通）
- 备机上 Nginx 虽运行，但 upstream 中后端服务未同步健康状态（如 max_fails 未触发摘除，导致请求仍打向已故障的 Tomcat）
- 主节点虽宕机，但 Keepalived 因心跳延迟或脑裂未及时降权，造成双 MASTER 状态，客户端 DNS 缓存或 TCP 连接残留持续打向原主节点，而该节点又部分响应（半死状态），加剧备机压力
检查备用机真实承载能力是否被低估
“容量不足”往往源于预估脱离实际运行态：
- 查看备机历史监控：CPU、内存、连接数（netstat -ant | wc -l）、TIME_WAIT 数量、磁盘 IO 等，对比主节点正常时的峰值，确认其硬件规格是否真能承接 100% 流量
- 检查 Nginx 配置是否一致且轻量：备机若误启了 realip、lua 脚本、geoip2 或过大的 proxy_buffer，会显著增加单请求开销；worker_processes 必须设为 auto 或明确小值（如 2），避免抢占过多 CPU
- 确认静态文件路径、SSL 证书、upstream 定义与主机完全一致——rsync 同步遗漏会导致 reload 失败或 fallback 到默认行为，引发隐性性能劣化
定位压垮发生的直接诱因
不是等压垮后再分析，要抓切换瞬间的关键指标：
- 日志时间对齐：比对主节点宕机时间、Keepalived 日志中 “Transition to MASTER STATE” 时间、Nginx error.log 中首个 “connect() failed” 或 “upstream timed out” 时间点，确认是切换滞后、还是切换后立即过载
- 连接数暴增模式：用 ss -s 或 netstat -s 查看是否大量 ESTABLISHED（说明连接建立成功但处理慢），还是大量 SYN_RECV（说明连接队列溢出，accept 队列满）——后者指向内核参数或 worker_connections 不足
- 上游异常放大：备机接管后，若后端服务本身已有延迟或错误率上升，proxy_next_upstream 会反复重试，形成请求风暴。检查 access.log 中 502/504 响应比例及重试次数（可加 $upstream_http_x_retry_count 变量记录）
验证与加固措施
压垮问题必须闭环验证，不能只调参：
- 在非高峰时段，手动触发 VIP 切换（ip addr del VIP/dev && systemctl stop keepalived），观察备机在真实流量下的 CPU、内存、请求成功率变化，而非仅压测静态页面
- 给备机配置独立限流：在 server 块中加 limit_req zone=perip burst=10 nodelay，防突发流量冲击核心服务
- 启用 slowlog：在 nginx.conf 加入 log_format slow '$time_local $request_time $upstream_response_time $status'；access_log /var/log/nginx/slow.log slow if=$slowreq；set $slowreq 0；if ($request_time > 5) { set $slowreq 1; }，快速识别慢请求来源
