least_time 是 Nginx Plus 独有策略，开源版不支持；它基于响应时间与活跃连接数动态选后端，需 zone 共享内存及 header/connect/last_byte 测量点，并建议搭配 slow_start、health_check 和 max_conns 使用。
least_time 是 Nginx Plus（商业版）独有的上游负载均衡策略，**开源版 Nginx 不支持该指令**。它通过实时监测后端节点的响应时间（包括连接、响应头接收等阶段），将新请求优先分发给“平均响应时间最短 + 当前活跃连接最少”的服务器，实现更精细的动态负载均衡。
前提条件：确认你用的是 Nginx Plus
开源 Nginx（nginx.org 发布的版本）中 least_time 指令根本不存在，配置会直接报错：unknown directive "least_time"。只有订阅了 Nginx Plus（如 R26+ 版本）才能使用。可通过以下方式验证：
- 运行
nginx -V 2>&1 | grep -i plus，输出含nginx-plus即为 Plus 版 - 访问
http://your-nginx/status（需启用ngx_http_status_module）可查看 Plus 特有指标
配置 least_time 的基本语法与关键参数
在 upstream 块中使用，必须配合 zone 指令启用共享内存以存储统计信息：
upstream backend {
zone backend 64k;
least_time header; # 或 connect / last_byte
server 192.168.1.10:8080;
server 192.168.1.11:8080;
server 192.168.1.12:8080;
}其中 least_time 后的参数决定响应时间测量点：
-
connect：仅计算 TCP 连接建立耗时 -
header：计算到收到响应头第一个字节的时间（含连接 + 请求发送 + 头部返回），最常用 -
last_byte：计算到完整响应体接收完毕的时间（含全部传输）
配合 slow_start 和 health_check 提升稳定性
单纯依赖响应时间可能放大抖动影响，建议组合使用：
-
slow_start=30s：新上线或恢复的服务器逐步增加流量，避免瞬间压垮 -
health_check interval=5 fails=3 passes=2：主动健康检查，及时剔除不可用节点 -
max_conns=100：限制单机最大并发，防止单节点过载拖慢整体响应时间统计
示例完整配置：
upstream backend {
zone backend 64k;
least_time header;
server 192.168.1.10:8080 slow_start=30s max_conns=128;
server 192.168.1.11:8080 slow_start=30s max_conns=128;
server 192.168.1.12:8080 backup;
health_check interval=5 fails=3 passes=2;
}监控与调优建议
启用 status 页面后，可在 JSON 接口（/status?format=json）中查看各节点的 response_time、response_time_count、active 等字段，用于验证策略效果。
- 若某节点
response_time持续偏高但active很低，可能是应用层瓶颈（如 DB 锁、GC），需排查后端而非调整 Nginx - 避免将
least_time与ip_hash或hash $request_uri混用，会导致策略失效 - 默认不启用平滑权重衰减，如需考虑历史表现，可搭配
queue指令控制等待队列行为
