least_conn容灾切换需与health_check协同实现秒级避让：通过模拟慢节点、网络抖动等故障，结合stub_status、access log和error log观测，确保5–10秒内完成流量转移，超8秒需调优参数。
测试 least_conn 的容灾切换效率，核心是验证当某台后端异常（如响应变慢、连接堆积、主动断连失败）时，Nginx 是否能快速识别并绕过该节点，把新请求导向真正空闲的机器——不是等它彻底宕机才切，而是“感知负载变化即响应”。这和健康检查（health_check）协同工作，但二者逻辑不同：health_check 判定节点是否存活，least_conn 决定流量往哪发。两者配合得好，才能实现秒级避让。
构造可控的故障注入场景
不能依赖真实故障，要主动模拟典型异常，确保每次可复现：
- 让一台后端故意返回超长延迟（如 sleep 15 秒），其余保持 100ms 响应，制造“慢节点”
- 或用 iptables 限速/丢包模拟网络抖动：sudo iptables -A OUTPUT -d 192.168.1.11 -m statistic --mode random --probability 0.2 -j DROP
- 禁用该后端的 keepalive 或强制关闭连接后不重用，使其 ESTABLISHED 连接数持续高位但无实际处理能力
- 确保 Nginx 启用了 health_check（如 interval=3s rise=2 fall=3），避免因单次超时误判下线
压测中实时观测切换行为
用 wrk 发起长连接压测（如 -c 200 -t 4 --timeout 30s），重点看三个指标在故障发生后的 5–10 秒内如何变化：
- stub_status 中各 upstream server 的 active connections 数：故障节点连接数应停止增长甚至缓慢下降，其他节点连接数明显上升
- 后端 access log 的请求数增量：故障节点新增请求数应在 2–3 个 health_check 周期内归零，其余节点承接全部新增流量
- Nginx error log 中的 connect timeout / upstream timed out 记录：若频繁出现，说明 least_conn 还在往故障节点发请求，或 health_check 未及时标记为 down
验证切换是否真正生效而非假象
容易忽略的干扰项会导致“看似切换成功”实则无效：
- 检查 keepalive 连接池是否过大（如 keepalive 256）：大量空闲长连接占着“连接数名额”，least_conn 会误以为该节点仍可用
- 确认后端未开启 TCP FIN_WAIT2 linger 或设置了过长的 SO_LINGER：导致连接未真正释放，Nginx 统计的 active connections 滞后失真
- 对比 round-robin 下同一故障场景：least_conn 应在更短时间内（通常 ≤ 5 秒）实现 95%+ 流量转移，而轮询可能持续向慢节点分发 20 秒以上
- 临时关闭 health_check，仅靠 least_conn 自身行为观察：此时它只能靠连接堆积被动规避，切换会变慢且不彻底——说明容灾必须两者配合
记录关键时间点与阈值
容灾效率最终要落在数字上，建议记录以下时间戳（从故障注入开始计时）：
- health_check 首次标记为 unhealthy 的时间
- least_conn 停止向该节点分发新请求的时间（通过 access log 时间戳差计算）
- 其他节点连接数上升斜率明显加快的时间点
- 整体 P95 延迟回落至正常水平的时间（表明流量已稳定重分布）
如果上述任意一项超过 8 秒，需检查 max_fails/fail_timeout 是否过于宽松，或 upstream 中未启用 keepalive 导致短连接干扰统计精度。
