least_conn需配合健康检查、错误兜底和连接复用策略才能绕过异常节点：显式配置max_fails/fail_timeout、proxy_next_upstream、keepalive及重试限制，并通过/nginx_status和日志验证跳过效果。
least_conn 本身不处理节点异常断开后的重分配，它只在新请求到来时，选择当前活跃连接数最少的节点。真正让流量绕过已断开或卡死节点的，是一套配合机制——健康检查、错误兜底和连接复用策略必须同时生效。
被动健康检查要足够灵敏
节点异常断开后，若 Nginx 还把它当作“可用”参与 least_conn 比较，新请求就会持续打过去，直到超时失败。关键在于让故障节点被快速标记为不可用：
- 每个 server 行必须显式配置 max_fails 和 fail_timeout，例如 server 10.0.1.10:8080 max_fails=1 fail_timeout=10s; —— 一次失败就下线，10 秒内不再转发
- 避免依赖默认值（max_fails=1, fail_timeout=10s），因为部分旧版 Nginx 默认是 max_fails=1 fail_timeout=0，即不自动恢复，需手动干预
- 搭配 proxy_next_upstream，至少包含 error timeout http_502 http_503，确保后端返回 502 或连接中断时，Nginx 立即重试其他节点
连接复用必须开启且对齐
如果 Nginx 到后端用的是短连接，每次请求都新建 TCP，那么节点断开后，下次建连失败会直接触发重试；但若用了 keepalive，空闲连接可能还挂在已断节点上，导致 least_conn 统计失真。所以：
- upstream 块中必须有 keepalive 32;，并配 proxy_http_version 1.1; 和 proxy_set_header Connection "";
- 后端服务（如 Tomcat、Spring Boot）也要开启连接池，并设置 keepAliveTimeout 略大于 Nginx 的 proxy_read_timeout，防止后端先断而 Nginx 不知
- 用 ss -tan | grep :8080 | grep ESTAB | wc -l 在后端机器上核对真实连接数，确认是否与 Nginx 的 /nginx_status 中 Active connections 一致
重试行为要有节制
不能无限制重试坏节点，否则放大问题。需主动限制容错边界：
- 设置 proxy_next_upstream_tries 2;，最多尝试两个节点，避免单次请求反复冲击同一故障路径
- 配合 proxy_next_upstream_timeout 5s;，整体重试耗时不超过阈值，防止用户长时间等待
- 若某节点长期处于 “down” 状态，可临时设 weight=0 并 reload 配置，实现秒级摘流，比等自动恢复更可控
验证是否真跳过了异常节点
别只看日志里有没有 502，要确认底层连接是否实际避开：
- 压测期间访问 /nginx_status，观察故障节点的 Active connections 是否持续为 0
- 在 log_format 中加入 $upstream_addr $upstream_response_time，对比各节点响应时间和请求占比
- 模拟节点断电或 kill -9 进程后，发起连续请求，检查前 3–5 次是否全部落到其他节点，且无明显延迟毛刺
