Nginx负载均衡集群高可用验证需覆盖三层：后端节点自动剔除与恢复、Nginx主备VIP秒级切换、业务连续性（会话、长连接、DB容灾及压测稳定性）。
测试 Nginx 负载均衡集群的高可用与容灾能力，关键不是“看配置有没有写对”，而是模拟真实故障场景，验证系统能否自动发现异常、隔离故障节点、维持服务连续性，并在恢复后正确重新纳入流量。整个过程需覆盖三层：Nginx 自身高可用（主备切换）、后端服务负载均衡（节点剔除/恢复）、以及业务层面连贯性（如会话、响应内容、时延）。
一、验证后端节点故障自动剔除与恢复
这是负载均衡最基础的容灾能力，重点测健康检查是否生效：
- 确保 upstream 中已配置 max_fails=3 fail_timeout=30s（或启用主动检查模块）
- 手动停掉一台后端服务（如
systemctl stop tomcat或kill -9对应进程） - 持续用 curl 或浏览器访问 VIP 或 Nginx 地址（如
curl http://192.168.3.100/test.html），观察返回内容是否始终来自存活节点（不报错、不超时、不轮到宕机节点） - 等待超过
fail_timeout时间（如 30 秒）后，再重启该后端服务；继续请求，确认流量在 1–2 分钟内逐步回归（Nginx 默认会周期性重试） - 查看 Nginx error 日志：
tail -f /var/log/nginx/error.log，应有类似upstream server ... failed和resolving upstream的记录
二、验证 Nginx 自身主备切换（Keepalived VIP 漂移）
这是防止单点失效的核心，测试目标是：主 Nginx 挂了，VIP 秒级迁移到备机，客户端无感知重连。
- 确认两台 Nginx 均运行 keepalived，且
vrrp_script chk_nginx正确检测 nginx 进程（如killall -0 nginx） - 在客户端执行持续 ping VIP：
ping 192.168.3.100，同时观察回复的 MAC 地址（可用arp -a | grep 192.168.3.100） - 在主节点执行：
systemctl stop keepalived（或killall keepalived） - 观察：ping 应短暂丢包（通常 ≤ 2 秒），随后恢复；ARP 表中 VIP 对应的 MAC 地址应变为备机网卡地址
- 用 curl 访问 VIP，确认仍能正常返回后端响应；登录备机执行
ip a | grep 192.168.3.100，确认 VIP 已绑定 - 重启主节点 keepalived，VIP 应自动切回（取决于 preemption 配置，默认开启）
三、验证业务连续性与容灾逻辑
避免“能通但不可用”——需结合具体业务特征设计验证点：
-
会话保持类应用：若用了
ip_hash，断开主 Nginx 后首次请求可能跳转新后端，但应能通过 Redis 共享 Session 继续操作；可登录后刷新页面，检查用户态未丢失 - 长连接服务（如 WebSocket）：主动断开主 Nginx 后，客户端应自动重连到新 VIP，且新连接被 least_conn 策略正确分发
- 数据库依赖场景：模拟从库宕机，确认应用仍可读主库（failover 配置生效）；或人为切断后端 DB 连接，观察 Nginx 是否快速返回 502/503，而非长时间挂起
-
压测下稳定性：用
wrk -t4 -c100 -d30s http://192.168.3.100/持续压测时，突然 kill 一个后端，观察错误率是否短暂上升后回落，平均延迟是否可控（
四、日志与指标交叉验证
仅靠肉眼刷新不够，需用数据佐证容灾真实生效：
- 查 Nginx access 日志：
awk '{print $1,$NF}' /var/log/nginx/access.log | tail -50，确认故障期间无访问宕机 IP 的记录 - 查 Keepalived 日志：
journalctl -u keepalived -n 50 --no-pager，应有Transition to MASTER/BACKUP state明确状态变更 - 用
ipvsadm -ln（若用了 LVS 层）或ss -tnp | grep :80观察连接分布，验证流量是否真实绕过故障节点 - 对关键接口加自定义健康探针（如
location /health { return 200 "OK"; }），配合 Prometheus + Alertmanager 实现故障自动告警
