核心是验证故障发生于真实流量洪峰时，服务连续性、状态切换准确性与后端影响三者同步达标：需在2–5万并发压测中注入进程崩溃、服务假死、网络隔离三类故障，通过客户端行为、日志比对、系统状态及后端影响四维交叉验证。
测试 Nginx 在高并发下故障转移触发时的整体稳定性，核心是让故障发生于真实流量洪峰中，并验证服务连续性、状态切换准确性与后端影响三者是否同时达标。不能只看 VIP 是否漂移，也不能只盯日志有没有报错——要抓客户端可感知的体验、系统级资源变化和组件协同行为。
在压测流量中主动注入三类典型故障
用 wrk 或 locust 持续发起 2–5 万并发请求（覆盖线上峰值 70% 以上），运行 2 分钟后，在第 90 秒精准触发以下任一操作：
-
进程崩溃：在主 Nginx 节点执行
systemctl stop nginx或kill -9 $(pgrep nginx)，观察 Keepalived 是否在 3–5 秒内完成降权与 VIP 漂移 -
服务假死：临时修改 upstream 配置，使
/health接口返回 503 或超时（如 proxy_pass 指向已关机后端），验证 HTTP 层探测能否识别异常，而非仅依赖进程存活 -
网络隔离：在主节点运行
iptables -A OUTPUT -p vrrp -j DROP，模拟心跳中断，确认 VRRP 是否稳定选举、避免脑裂
用客户端行为验证真实服务连续性
故障切换不是“VIP 能 ping 通”就结束，必须模拟终端用户访问行为：
- 持续执行：
watch -n 0.2 'curl -sI http://VIP | head -1 2>/dev/null'，切换瞬间最多允许 1–2 次Connection refused或超时，之后应立即恢复HTTP/1.1 200 OK - 浏览器反复 F5 刷新页面，或运行长连接压测：
ab -n 1000 -c 50 http://VIP/，失败请求数应为 0 - 比对主备节点
access.log：主节点最后一条日志时间戳，与备节点第一条日志时间戳误差 ≤ 1 秒，体现无缝衔接
交叉验证关键系统状态是否真实切换
仅靠日志判断容易误判，需三处输出同步比对：
-
VIP 绑定状态：故障期间分别在主备节点执行
ip a | grep "inet.*VIP"，VIP 应仅出现在备机网卡上 -
Keepalived 状态流：查
tail -f /var/log/messages | grep Keepalived，应看到完整变迁，例如主节点出现MASTER → FAULT → BACKUP，备节点出现BACKUP → MASTER -
Nginx worker 进程与连接状态：执行
ps aux | grep nginx确认新旧 worker PID 切换；用ss -s和stub_status观察 Active connections 是否平稳过渡，无断崖式下跌
检查后端是否被错误连带影响
故障转移不该引发后端雪崩或重试风暴：
- 查看各后端
access.log和error.log，确认无大量重复请求、超时或 502/504 日志突增 - 若配置了
proxy_next_upstream，需确认重试次数未超出预期（如设为error timeout http_502，则仅在对应错误时重试） - 用
tcpdump抓包分析主备切换前后，Nginx 与后端之间的连接建立/关闭行为，避免因连接池复用混乱导致 RST 泛滥
