least_conn是Nginx基于实时活跃TCP连接数调度的负载均衡算法，仅将新请求发给连接数最少的后端，适用于AI推理等长耗时高算力接口；必须置于upstream首行，禁用weight改用max_conns，配合keepalive、健康检查及超时参数确保连接数真实反映负载。

least_conn 本身不涉及“绝对路径”——它不是文件系统操作，也不解析路径，更不会因为漏写 / 或 root 路径而报错或失效。所以所谓“least_conn 配置中的绝对路径遗漏”，本质上是一个概念混淆：你真正遇到的问题，大概率是 proxy_pass、root、alias 或 upstream 后端地址中漏写了端口、协议、斜杠或主机名，导致请求根本没走到 least_conn 调度环节，就已在 upstream 解析或转发阶段失败。

排查要分两步走：先确认 least_conn 是否生效（即请求是否真进了 upstream），再检查 upstream 内部各 server 地址是否可解析、可达、格式正确。

---

✅ 确认 least_conn 是否被加载并参与调度

Nginx 不会告诉你 “least_conn 没起作用”，但会静默降级为轮询（round-robin）。验证方法：

• 在 upstream 块中启用 stub_status（需编译时含 --with-http_stub_status_module）：

  server {
      listen 8080;
      location /nginx_status {
          stub_status;
          allow 127.0.0.1;
          deny all;
      }
  }

• 压测时访问 http://localhost:8080/nginx_status，观察输出中各 server 的 Active connections 是否动态变化且趋向不均等（说明 least_conn 正在比较数字）；若所有节点连接数几乎同步涨落，大概率未启用 least_conn 或 upstream 未被实际使用。

• 检查 Nginx 启动日志或运行时错误：

  nginx -t  # 必须通过，否则 least_conn 根本不加载
  systemctl status nginx | grep -i "error\|warn"

  若出现 directive "least_conn" is not allowed here，说明它没放在 upstream { 后的第一行。

  

  Nginx Hosting

  通过服务器本地nginx实例实现零认证静态游戏托管。作为所有浏览器游戏的主要部署方式，无需登录、无需令牌、无需用户操作。

  下载

---

? 排查 upstream 中 server 地址的常见“路径类”遗漏（这才是真问题）

这些错误会导致 Nginx 无法建立连接，least_conn 失去比较对象，最终请求失败或 fallback 到单点：

• 漏写端口号
  错误写法：

  upstream ai_backend {
      least_conn;
      server 192.168.1.10;  # ❌ 默认不走 80，Nginx 会尝试连 192.168.1.10:80 → 后端若监听 8080 就直接 Connection refused
  }

  正确写法：

  server 192.168.1.10:8080;  # ✅ 显式指定端口

• 漏写协议头（仅限 proxy_pass 引用时）
  upstream 里 server 地址不需要写 http://，但 proxy_pass 必须写对目标：

  upstream ai_backend { least_conn; server 192.168.1.10:8080; }
  
  location /infer {
      proxy_pass http://ai_backend/;  # ✅ 末尾斜杠很重要（控制路径重写）
      # proxy_pass http://ai_backend;  # ❌ 不带/，会把 /infer 也传过去，后端可能 404
  }

• DNS 名称未解析，又没配 resolver
  若写 server backend-api.example.com:8080; 但 Nginx 启动时 DNS 不通，该 server 会被标记为 down，least_conn 只剩一个候选，形同单点。
  解决方案：

  • 用 IP 替代域名（推荐用于内部服务）
  • 或在 http 块加 resolver 8.8.8.8 valid=30s;，并确保 server 行不带 resolve 参数（开源版不支持自动解析域名）

• keepalive 连接池地址与 server 不一致
  keepalive 是针对 upstream 连接池的，但它依赖 server 行地址完全匹配（包括端口、IP/域名）：

  upstream ai_backend {
      least_conn;
      server 192.168.1.10:8080;   # ← 这个地址
      keepalive 32;
  }

  如果后端实际监听的是 192.168.1.10:8081，keepalive 缓存的连接永远连不上，连接频繁新建断开 → least_conn 统计失真 → 表现像“没生效”。

---

? 快速定位：三行命令查清根源

# 1. 看配置是否加载成功（尤其 least_conn 位置）
nginx -T 2>/dev/null | sed -n '/upstream.*ai_backend/,/}/p' | head -10

# 2. 看 upstream 中 server 是否被标记为 down（说明地址不可达）
curl -s http://localhost:8080/nginx_status | grep -A5 "Upstream"

# 3. 手动模拟一次连接，验证后端地址+端口是否通
timeout 3 bash -c 'echo -n > /dev/tcp/192.168.1.10/8080' && echo "OK" || echo "FAIL"

只要 server 地址写全（IP+端口）、proxy_pass 指向正确的 upstream 名、least_conn 在 upstream 块首行，它就会工作——它不关心路径，只数连接数。所谓“路径遗漏”，九成是 upstream 地址或 proxy_pass 写错了。