least_conn本身不直接导致502，但配置不当会将请求持续分发至假死节点，引发偶发502；需配合主动健康检查、proxy_next_upstream重试及合理上游配置协同防御。
least_conn 本身不会直接引发 502，但配置不当会让 Nginx 把请求持续压向“看似空闲、实则已假死”的后端节点，从而触发偶发性 502。这类问题往往日志无明显报错、重启临时缓解、复现不稳定，排查关键在于识别“幽灵节点”和补全健康防护机制。
确认 least_conn 是否真正生效
很多人加了 least_conn 就以为负载均衡起作用了，其实它只在 upstream 块中启用，且依赖多节点才有效：
- 运行
nginx -t验证语法，再执行nginx -s reload确保配置重载成功 - 检查 upstream 定义是否至少包含两个正常 server，例如：
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 优先选连接数最少的节点，但连接数少 ≠ 健康。一个线程卡死、数据库连接耗尽、或长时间 GC 的节点，可能仍能建 TCP 连接，却无法返回完整响应，Nginx 在读取时超时或收到截断连接，最终返回 502。
- 查该节点实时连接数：
ss -ant | grep :8080 | wc -l，对比其他节点是否显著偏低 - curl 直连测试：
curl -v http://10.0.1.10:8080/health，观察是否卡在* Connected后无响应，或返回不完整 HTTP 头 - 检查该节点应用日志：搜索
OutOfMemoryError、Connection reset、GC pause > 1s等线索
补全主动健康检查与容错机制
least_conn 默认不带主动健康检查（active health check），只要端口通就认为“活着”，这是偶发 502 最隐蔽的根源。
- 在 upstream 中为每个 server 显式添加失败判定参数：
server 10.0.1.10:8080 max_fails=3 fail_timeout=30s; - 配合
proxy_next_upstream实现自动重试：proxy_next_upstream error timeout invalid_header http_500 http_503; - 避免重试放大压力，禁用
http_502和off以外的非必要状态码重试
同步优化 Nginx 代理缓冲与超时参数
即使后端勉强响应，若缓冲区过小或超时太短，Nginx 仍可能因截断或提前中断而返回 502。
- 增大响应缓冲：
proxy_buffer_size 128k;<br>proxy_buffers 4 128k;<br>proxy_busy_buffers_size 256k;<br>proxy_temp_file_write_size 256k;
- 延长关键超时（尤其读取）：
proxy_connect_timeout 60s;<br>proxy_send_timeout 60s;<br>proxy_read_timeout 120s;
（根据业务响应时长合理上调） - 启用 keepalive 复用连接，减少握手开销：
upstream backend {<br> least_conn;<br> keepalive 32;<br> server 10.0.1.10:8080;<br> server 10.0.1.11:8080;<br>}<br>location / {<br> proxy_pass http://backend;<br> proxy_http_version 1.1;<br> proxy_set_header Connection "";<br>}
