least_conn仅在本层upstream内生效，统计直连后端的TCP连接数；多级链路中需分层验证、禁用缓存与短连接干扰、透传trace-id追踪路径，并通过stub_status、ss命令和debug日志三端比对连接数一致性。
测试 least_conn 在多级代理链路中的调度准确性，核心是确认请求最终落到的后端节点，确实为“当前活跃连接数最少”的那个——而不是被中间某层代理的连接复用、缓存或统计延迟干扰判断。多级链路（如 Client → CDN/边缘 Nginx → 网关 Nginx → 后端服务）会放大连接归属错位、计数不同步、健康状态失真等问题，必须分层隔离验证。
明确每层 least_conn 的作用域和统计主体
least_conn 只在它所在的 upstream 块内生效，且只统计该 Nginx 实例与直连后端之间的 TCP 连接数。不能跨层传递“全局最少”概念：
- 边缘层 Nginx（如 CDN 节点）的 least_conn，只看它自己到网关层的连接数，不感知网关到后端的连接压力
- 网关层 Nginx 的 least_conn，只统计它与后端服务之间的连接，与上游是否复用无关
- 若某层禁用了 keepalive（如边缘层设 proxy_http_version 1.0），则其 upstream 连接全为短连接，least_conn 失效——此时看到的“连接数”只是瞬时握手峰值，无调度意义
构造可追踪的压测路径并禁用干扰机制
用唯一标识贯穿整条链路，确保能定位每个请求最终到达的后端实例：
- 在客户端请求头中注入唯一 trace-id（如 X-Trace-ID: t-abc123），各层 Nginx 透传该 header，后端记录到 access log
- 关闭所有中间层的 proxy_cache、proxy_buffering 和 gzip（避免响应体变形或延迟释放连接）
- 每层 upstream 显式配置 keepalive 32 和 proxy_http_version 1.1; proxy_set_header Connection '';，确保连接真正复用而非伪装
- 禁用边缘层的健康检查（如 max_fails=0），只让网关层做真实健康判定；否则边缘可能因误判将流量长期固定到某台网关，掩盖 least_conn 行为
分层采集连接数并交叉比对一致性
不能只信某一层的 stub_status，要三端数据对齐：
- 在网关层 Nginx 开启 stub_status，定时抓取 /nginx_status 中各 backend server 的 Active 字段值
- 在每台后端机器上执行 ss -tn state established '( dport = :8080 )' | wc -l，获取真实 ESTABLISHED 连接数
- 在网关层 Nginx 的 error_log 中开启 debug 级别（仅测试），过滤 "upstream connection" "free keepalive connection"，确认连接建立/释放日志是否与后端 ss 统计跳变严格同步（理想偏差 ≤ 1 秒）
- 若发现网关层 stub_status 显示某 backend Active=5，但后端 ss 查出 12 个连接，说明存在连接未释放（如后端 linger 未关）或 proxy_ignore_client_abort off 导致断连不通知
验证链路扰动下的动态响应能力
模拟真实故障场景，观察 least_conn 是否仍能准确识别“空闲节点”：
- 在网关层后端列表中，对其中一台（如 192.168.2.20）执行 iptables -A OUTPUT -p tcp --dport 8080 -j DROP 持续 10 秒，制造主动断连
- 同时用 wrk 并发 100 压测，持续 60 秒，记录每 5 秒各后端 access log 中带相同 X-Trace-ID 的请求数量
- 预期结果：断连恢复后的前 3 秒内，该后端请求数应接近 0；其余后端请求数瞬时上升，且上升比例与它们当前 Active 连接数负相关（即连接越少，承接越多）
- 若断连节点在恢复后立即收到大量新请求，说明 least_conn 统计滞后或健康检查未触发 fail_timeout 清除其连接计数
