关键在于聚焦故障触发后前10秒（尤以第3–8秒峰值为准），通过毫秒级时间戳对齐抓包、日志与系统指标，精准定位连接风暴、DNS缓存未刷新、免费ARP同步延迟等瞬时瓶颈，而非等待系统“恢复后”分析。
排查 Nginx 故障转移切换瞬间的瞬时延迟尖峰，关键不是等“系统恢复正常后再看日志”，而是聚焦故障触发后前 10 秒内真实发生的资源争抢与行为叠加。这个窗口期决定了用户是否感知卡顿、超时或重复提交。
抓准时间锚点：从故障触发到首请求抵达的毫秒级链路
延迟尖峰往往出现在第 3–8 秒，原因包括：客户端重连爆发、Nginx 连接池重建、上游 DNS 缓存未刷新、免费 ARP 未被交换机/网关及时同步。必须用精准时间戳对齐各环节：
- 在主节点执行 iptables -A INPUT -p tcp --dport 80 -j DROP 的时刻记为 T₀
- 用 tcpdump -i ens33 -nn port 80 在备用节点抓包，标记首个 SYN 到达时间（T₁）
- 在 Nginx access_log 中启用 $request_time $upstream_response_time $time_iso8601，定位 T₁±2 秒内的请求耗时分布
- 对比 T₁ 与首次成功响应的时间差，若 >500ms 且集中出现在同一秒，即为瞬时尖峰起点
验证连接风暴是否真实发生
静态并发压测会掩盖脉冲特征。真实故障转移中，连接是“挤”出来的：
- 检查 ss -s | grep "SYNs to LISTEN"，观察 T₀ 后 5 秒内新建连接数是否突增 3 倍以上
- 用 netstat -s | grep -i "retransmitted" 查重传率，若 >2%，说明 TCP 层已因连接重建密集而丢包
- 若 upstream 使用域名，确认 resolver 配置中 valid=30s 是否生效——DNS 缓存未过期会导致流量仍打向旧 IP
隔离 Nginx 自身瓶颈
区分延迟来自 Nginx 处理还是后端承接能力不足：
- 比对 $request_time 与 $upstream_response_time：若前者显著大于后者（如 1200ms vs 80ms），说明 Nginx 在做连接复用、SSL 握手或 rewrite 等操作时出现排队
- 检查 worker_processes auto 和 worker_connections 是否匹配当前 CPU 核数与预期连接峰值；不足时会出现 accept queue 溢出（ss -lnt | grep :80 中 Recv-Q 持续 >0）
- 临时关闭 gzip、access_log、rewrite 规则，仅保留 proxy_pass，再复现故障——若尖峰消失，问题就在这些模块的初始化开销上
排除外部干扰项
很多“延迟”其实来自客户端或网络设备，并非 Nginx 本身问题：
- 浏览器或 SDK 的指数退避重试（如 100ms → 200ms → 400ms）会在第 2–3 次重试时形成第二波尖峰，需在前端埋点或抓包确认
- 交换机/路由器未及时响应免费 ARP，导致部分客户端仍向原 MAC 发包，直到 ARP 缓存超时（Linux 默认 60 秒），可用 arping -I ens33 -c 3 192.168.1.160 验证 VIP 的 MAC 是否已更新
- keepalived 的 vrrp_script 若依赖 curl 检查本地 Nginx 状态，其 timeout 设置过长（如 3s）会拖慢故障判定，应设为 ≤500ms
