关键在于精准触发、可观测、可验证：需kill主Nginx进程，同步用curl持续探测，以T0（kill时刻）、T1（备机升主日志）、T2（备机首次返回200）计算真实切换耗时，并通过抓包、日志、禁缓存验证真切换。
实际测试 Nginx 故障转移的秒级延时，关键在于**精准触发、可观测、可验证**——不能只看 VIP 是否飘走，而要确认请求真正被备用节点承接且无中断。以下是可落地的操作方式：
1. 模拟真实故障并控制触发时机
直接 kill nginx 进程是最贴近生产异常的方式，比 systemctl stop 更可靠（避免 systemd 自动拉起干扰）：
-
主节点执行：
kill -9 $(pgrep -f "nginx: master")，立即终止主 Nginx 服务 - 同步在另一窗口运行持续探测命令，如：
while true; do date +%T.%3N; curl -s -o /dev/null -w "%{http_code}\n" http://192.168.2.100/health || echo "fail"; sleep 0.5; done - 注意：健康检查脚本（如
check_nginx.sh）必须已启用，且interval 2表示 Keepalived 每 2 秒检测一次，首次失败后需再等一个周期才触发切换
2. 精确测量切换耗时的三个时间点
用时间戳对齐日志与请求响应，定位真实延迟来源：
-
T0：执行
kill的瞬间（记录系统时间） -
T1：备节点
/var/log/messages中出现"VRRP_Instance(VI_1) Entering MASTER STATE"的时间戳 -
T2：探测请求首次返回
200（且来自备节点真实 IP）的时间戳 - 切换延时 ≈ T2 − T0；通常为 2–4 秒（取决于
advert_int、check_nginx.sh执行间隔、网络延迟）
3. 验证是否真切换而非缓存或重试掩盖
避免误判，需排除客户端/中间件干扰：
- 用
curl -v或tcpdump -i eth0 host 192.168.2.100抓包，确认 TCP 握手目标 MAC 地址已变为备机网卡地址 - 在备节点
nginx access_log中搜索该次请求的remote_addr，确认日志时间与 T2 一致 - 禁用浏览器缓存或使用
curl -H "Cache-Control: no-cache"，防止 304 响应造成“服务未中断”的假象
4. 常见延时偏长的原因与速查
若实测超过 5 秒，优先检查以下配置项：
-
vrrp_instance中advert_int 1（建议设为 1，非默认 1 秒可能被改大） -
track_script的interval 2和脚本内sleep 2是否叠加导致检测延迟翻倍 - 主备节点时间不同步（
ntpq -p验证），影响日志时间比对准确性 - 防火墙拦截 VRRP 多播包（端口 443？错——VRRP 使用 IP 协议号 112，需放行协议 112，非端口）
