502错误在least_conn负载均衡下主因是配置冲突而非算法缺陷，需重点排查健康检查缺失、后端accept队列溢出、超时参数不合理、地址解析异常及系统级拦截等问题。
502 错误在使用 least_conn 负载均衡时，往往不是算法本身的问题，而是配置与其他机制发生隐性冲突——比如健康检查未启用、后端连接队列溢出、或超时参数与 least_conn 的“倾向性”叠加放大失败。排查重点不在“least_conn 是否生效”，而在“它把请求发给了谁？对方是否真能接住？”
确认 least_conn 是否真正起作用
很多人以为加了 least_conn 就自动负载均衡，其实它只是 upstream 的调度策略，前提是：所有 server 都处于 live（健康）状态。如果某个节点因配置错误被 Nginx 主动标记为 down，least_conn 就只剩一个可选节点，高并发下极易压垮它并引发 502。
- 检查 upstream 块是否启用了主动健康检查：
health_check interval=3 fails=2 passes=2;；没有它，Nginx 不会自动剔除卡死但进程仍在的后端 - 运行
curl -s 'http://127.0.0.1:8080/nginx_status' | grep "Active connections"（需开启 stub_status）或直接查upstream状态页（如用 nginx-plus 或 openresty） - 用
nginx -T 2>&1 | grep -A 10 "upstream.*least_conn"确认配置被正确加载，避免被其他 include 文件覆盖
检查后端 accept 队列是否溢出
least_conn 会持续把新请求导向连接数最少的节点，但若该节点的内核 accept 队列已满（Recv-Q 达到 listen backlog），新 TCP 连接就卡在 SYN_SENT，Nginx 日志会报 connect() failed (111: Connection refused) 或 upstream timed out (110)——这不是配置写错，而是系统级瓶颈。
- 在后端机器上执行：
ss -lnt | grep :8080，观察Recv-Q值是否长期 ≥Send-Q（默认常为 128） - 临时调大：修改后端服务的
net.core.somaxconn（如设为 4096）并重启服务；Java 应用还需在启动参数加-Dsun.net.listenBacklog=4096 - 搭配
least_conn使用时，更要监控单节点连接数突增——它不像 round-robin 那样“匀着分”，容易形成短时热点
验证 proxy_timeout 与 least_conn 的协同逻辑
least_conn 会让 Nginx 更“执着”地尝试向当前最空闲的节点建连。但如果该节点响应慢、偶发卡顿，而 proxy_connect_timeout 又太短（如默认 60s），Nginx 会在重试时反复打向同一个节点，加剧其压力，最终触发 502。
- 在 upstream 中显式设置：
proxy_connect_timeout 15s;（建连不拖沓）、proxy_read_timeout 90s;（给业务合理耗时） - 务必配合
max_fails=2 fail_timeout=30s;，让 Nginx 在连续失败后快速将该节点标记为不可用，避免 least_conn 持续“送人头” - 禁用 keepalive 时，
least_conn效果会打折；建议加上keepalive 32;并在 location 中启用 HTTP/1.1：proxy_http_version 1.1; proxy_set_header Connection "";
排除 upstream 地址解析与权限类冲突
least_conn 对后端地址的稳定性更敏感。若 upstream 中混用域名和 IP、或 DNS 解析不稳定，Nginx 可能将不同 worker 进程解析出不同 IP，导致连接分布失衡；SELinux 或防火墙拦截特定后端端口也会让 least_conn “选中即失败”。
- 统一使用 IP 地址配置 upstream，避免
server api.example.com:8080;这类写法；如必须用域名，加resolve指令并配好 resolver - 检查 SELinux 状态：
getenforce，若为 enforcing，临时设为 permissive 测试：sudo setenforce 0 - 用
telnet 192.168.1.10 8080和curl -v http://192.168.1.10:8080/health从 Nginx 所在机器直连每个后端，确认无网络层拦截
