least_conn在抖动重连场景下能动态精准分流：通过客户端侧注入延迟与断连、后端返回503/RST、禁用keepalive构造真实抖动，结合stub_status、ss命令和debug日志验证连接计数实时性，确保断连后1秒内计数更新，并在重连时优先调度空闲节点。
测试 least_conn 在网络抖动重连场景下的动态分流表现，核心是验证它能否在连接频繁中断、重建的波动中，仍持续把新请求导向真正“空闲”的后端节点——而不是被断连残留、重试堆积或统计延迟带偏。关键不在看平均分布，而在观察抖动发生瞬间的调度响应是否及时、准确。
模拟真实抖动链路
不能只靠丢包工具（如 tc netem）在后端链路上做随机丢包，那样无法复现客户端侧因网络不稳反复建连的行为。应分层构造抖动：
- 在压测客户端侧注入抖动：用 wrk 的 --latency + 自定义 Lua 脚本，在每次请求前随机 sleep 50–500ms，并以 5%–15% 概率主动关闭当前连接后重开
- 后端服务配合返回可控错误：例如每 10 个请求中，随机返回一次 HTTP 503 或直接 TCP RST（用 socat 或 mock 服务实现），触发 Nginx 的重试逻辑
- 禁用后端 keepalive：设 keepalive_timeout 0，确保每次重连都是全新 TCP 握手，放大连接数波动
重点监控连接生命周期指标
least_conn 的判断依据是 Nginx worker 进程内维护的活跃连接计数，抖动下最易失真是“连接已断但计数未减”。需交叉验证三类数据：
- 通过 stub_status 查 Active connections 和各 upstream server 的 Active 字段，每 2 秒抓一次，观察抖动发生时数值跳变是否同步（理想情况：RST 后 1 秒内计数 −1）
- 用 ss -tn state established | grep :8080 | wc -l 在后端机器上直查 ESTABLISHED 连接数，与 Nginx 统计值比对，偏差超过 3 个需检查 proxy_ignore_client_abort off 是否误配
- 开启 Nginx 的 debug 日志级别（仅限测试），过滤 "upstream connection" "free keepalive connection" 关键词，确认连接释放日志是否紧随 RST 出现
验证重连后的分流倾向性
抖动不是目的，重连后流量是否“聪明绕开”刚经历断连的节点，才是 least_conn 生效的标志。操作要点：
- 让两台后端中的一台（如 192.168.1.10）固定每 30 秒触发一次网络闪断（用 iptables DROP/ACCEPT 切换），另一台保持稳定
- 用 wrk 并发 200，持续压测 3 分钟，期间记录每 10 秒各后端 access.log 的请求数
- 对比抖动窗口（断连后 5 秒内）的请求分发：若 least_conn 正常，稳定节点请求数应瞬时上升 40% 以上，而刚恢复的节点在连接重建完成前应几乎无新请求（计数为 0 或极低）
- 若发现抖动后两台请求数仍接近轮询比例，检查是否未启用 proxy_next_upstream error timeout http_503 —— 缺少该配置时，Nginx 不会因 503 主动重试，也就不会触发重新走 least_conn 选节点
排除健康检查干扰
被动健康检查（max_fails/fail_timeout）在网络抖动中容易误判节点下线，反而掩盖 least_conn 的真实调度行为。测试时应：
- 临时调高 max_fails 至 10，fail_timeout 至 300s，避免抖动导致节点被摘除
- 禁用主动健康检查（如 health_check 指令），防止探测请求本身加剧连接波动
- 确认所有 server 行末尾未加 down 或 backup，保证所有节点始终参与 least_conn 计算
