故障转移切换后前3–8秒出现瞬时响应恶化，核心是连接风暴、DNS缓存残留与代理超时配置失配；需通过毫秒级时间锚点定位尖峰起点，压住重连爆发、预热备用节点、收紧超时重试及调优系统连接参数。
故障转移切换瞬间出现明显延迟，核心问题不在“切没切成功”，而在于切换后前几秒内请求堆积、连接重建和资源争抢导致的瞬时响应恶化。优化重点是压缩这关键10秒内的抖动，不是单纯调大超时或加机器。
抓准时间锚点，定位尖峰真实起点
延迟尖峰通常集中在故障触发后第3–8秒，必须用毫秒级时间戳对齐各环节：
- 在主节点执行故障注入命令（如 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 秒内的日志行
- 若该窗口内大量请求 $request_time > 500ms 且集中在同一秒，就确认是瞬时尖峰起点，后续所有优化都围绕这个时间窗展开
压住连接风暴与 DNS 缓存残留
真实切换不是平滑过渡，而是客户端重连爆发+Nginx重建连接池+DNS未刷新三重叠加：
- 用 ss -s | grep "SYNs to LISTEN" 查 T₀ 后5秒内新建连接是否突增3倍以上；若属实，说明客户端在疯狂重连
- 检查 upstream 是否用域名；若是，确认 resolver ... valid=30s 生效，避免 DNS 缓存未过期仍打向已下线 IP
- 在备用节点提前预热：用 curl 循环请求上游服务，让 resolver 缓存、SSL 会话复用、TCP 连接池提前建立
- 临时关闭 Nginx 的 gzip、access_log、rewrite，仅保留 proxy_pass；若尖峰消失，说明模块初始化开销是主因
收紧代理层超时与重试逻辑
超时值不匹配会导致“假失败”和无效重试，放大尖峰：
- proxy_connect_timeout 设为 3–5 秒（不超过后端 accept 队列响应延迟）
- proxy_read_timeout 略大于后端 P95 耗时（例如后端 P95 是 8s，此处设 12–15s），避免误判超时
- 必须配置 proxy_next_upstream error timeout http_502 http_503 http_504，让超时自动转发，而非卡死等待
- 搭配 proxy_next_upstream_tries 2 和 proxy_next_upstream_timeout 8s，限制整轮重试总耗时，防雪崩
加固底层连接与系统资源水位
Nginx 自身处理能力不足时，延迟会直接体现在$request_time远大于$upstream_response_time：
- 检查 worker_processes auto 和 worker_connections 是否匹配 CPU 核数与峰值连接预期；不足时 ss -lnt | grep :80 中 Recv-Q 持续 > 0
- 调大内核参数：net.core.somaxconn = 20480、fs.file-max = 1048576，并确保 ulimit -n ≥ worker_processes × worker_connections
- 启用 multi_accept on 和 use epoll，提升单 worker 接收并发连接效率
- 若使用 keepalive 复用上游连接，确保 upstream 块中配置了 keepalive 32 并在 location 中开启 proxy_http_version 1.1; proxy_set_header Connection '';
