Nginx 的 least_conn 算法只能在 upstream 块内首行启用，不可置于 location 中；需为不同 location 分配独立 upstream 块来实现差异化负载均衡，各 upstream 可单独配置 least_conn 及其他参数。
Nginx 的 least_conn 算法不能按 location 块单独启用，它只作用于 upstream 块内部，且必须作为该块内的首条指令出现。location 是请求路由层，不参与负载均衡策略的选择逻辑。
你无法写成这样（错误）：
location /api/v1/ {
least_conn; # ❌ 语法错误：least_conn 不允许出现在 location 中
proxy_pass http://backend_v1;
}真正生效的配置结构只能是：
upstream backend_v1 {
least_conn; # ✅ 必须放在 upstream 块第一行
server 192.168.1.10:8080;
server 192.168.1.11:8080;
}
upstream backend_v2 {
least_conn;
server 192.168.1.20:8080;
server 192.168.1.21:8080;
}
server {
location /api/v1/ {
proxy_pass http://backend_v1; # 调用已配 least_conn 的 upstream
}
location /api/v2/ {
proxy_pass http://backend_v2; # 调用另一组 least_conn upstream
}
}所以，“针对不同 location 单独启用”实际是通过为每个 location 分配独立的 upstream 块来实现的。关键点如下：
- 每个
upstream块可独立配置least_conn，互不影响 - 同一 upstream 内不可混用
ip_hash、hash、least_time等互斥算法 -
least_conn不接受参数，加weight不影响连接数判断逻辑，仅在连接数相同时起排序作用 - 若需差异化行为（如
/upload用长连接 + least_conn，/static用轮询），就建两个 upstream，分别配不同算法和 keepalive 参数
常见搭配建议：
- 对耗时接口（如
/api/compute）：用least_conn+keepalive 32+ 主动健康检查 - 对静态资源（如
/assets）：用默认轮询或ip_hash，无需least_conn - 对 WebSocket 或长连接服务（如
/ws）：least_conn天然更公平，但需确保后端支持并配置proxy_http_version 1.1和Connection ''
只要 upstream 定义清晰、proxy_pass 指向明确，location 就能“间接”使用各自专属的 least_conn 策略。
