least_conn 本身不直接导致502，但配置不当或缺失健康检查时，会将请求持续分发至假死节点，引发偶发502；需配合主动健康检查、proxy_next_upstream重试及合理上游配置协同防御。
least_conn 是 Nginx upstream 的一种负载均衡算法，意思是“把新请求优先分给当前连接数最少的后端节点”。它本身不会直接导致 502，但一旦配置不当或与实际运行状态不匹配，就会放大上游服务的脆弱性，从而引发偶发性 502。这类问题难在“不总发生、日志无明显报错、重启后暂时恢复”，本质是 least_conn 把流量悄悄压向了那个“看似空闲、实则已假死”的节点。
确认 least_conn 是否真正在起作用
很多人以为加了 least_conn 就生效了，其实它只在 upstream 块中启用，且需配合健康检查才能发挥价值。先验证配置是否被正确加载：
- 运行
nginx -t确保语法无误，再执行nginx -s reload - 检查 upstream 定义是否完整，例如：
upstream backend {<br> least_conn;<br> server 10.0.1.10:8080;<br> server 10.0.1.11:8080;<br>} - 注意：如果 upstream 中只写了一个 server，least_conn 就退化为直连，完全不起作用——这种配置在灰度发布或单节点扩容初期很常见，容易被忽略
排查 least_conn 下的“幽灵节点”
least_conn 会持续把请求打向连接数最少的节点。但如果某个节点进程还在、端口也通，只是内部线程卡死、数据库连接耗尽、或 GC 暂停时间过长，它对外仍表现为“可连接、有响应头、但响应体迟迟不来”，Nginx 就可能在读取响应时超时或收到截断连接，最终返回 502。
- 查该节点实时连接数：
ss -ant | grep :8080 | wc -l（对比其他节点是否显著偏低） - 用 curl 直连该节点：
curl -v http://10.0.1.10:8080/health，观察是否响应缓慢、卡在* Connected后无后续，或返回不完整 HTTP 头 - 检查该节点应用日志里是否有
OutOfMemoryError、Connection reset、长时间 GC 日志，这些都会让 least_conn “误判”其健康状态
检查健康检查是否缺失或失效
least_conn 默认不带主动健康检查（active health check）。也就是说，只要 TCP 连接能建起来，Nginx 就认为这个节点“活着”，哪怕它已经无法处理任何业务请求。这就是偶发 502 最隐蔽的来源。
- 在 upstream 中显式添加健康检查：
upstream backend {<br> least_conn;<br> server 10.0.1.10:8080 max_fails=3 fail_timeout=30s;<br> server 10.0.1.11:8080 max_fails=3 fail_timeout=30s;<br> health_check interval=5 fails=3 passes=2 uri=/health;<br>} - 确保后端
/health接口真实有效：不仅返回 200，还要校验数据库连接、缓存连通性等关键依赖 - 若用的是开源版 Nginx（非 Plus），
health_check指令不可用，需改用proxy_next_upstream配合失败重试来兜底
验证 proxy_next_upstream 是否覆盖了 least_conn 的缺陷
least_conn 是“选节点”，而 proxy_next_upstream 是“换节点”。当 least_conn 选中的节点出问题时，靠它来自动 fallback 才能避免 502。
- 在 location 块中必须配置：
proxy_next_upstream error timeout http_502 http_503 http_504;
尤其不能漏掉http_502——否则上游返回 502，Nginx 就原样透传，不会尝试下一个节点 - 同时设置重试次数和超时：
proxy_next_upstream_tries 3;<br>proxy_next_upstream_timeout 10s;
- 注意：如果 upstream 只有两个节点，且都因同一原因（如共用 DB 挂掉）返回 502，重试也无效，此时要回归到依赖服务本身的高可用
