least_time是Nginx Plus特有的负载均衡算法，依据响应时间（connect/header/last_byte）动态选最快节点，开源版不支持；需验证nginx-plus版本、模块加载及文档标识。
在 Nginx 中，least_time 是商业版 Nginx Plus 特有的负载均衡算法，它根据上游服务器的响应时间（包括连接、写入、读取阶段）动态选择最快节点，比 least_conn 或 round_robin 更适合对延迟敏感的业务。开源版 Nginx 不支持该指令，切勿在免费版本中尝试配置，否则会报错 unknown directive "least_time"。
确认你使用的是 Nginx Plus
该算法仅存在于 Nginx Plus（R12 及以后版本），需通过官方订阅获得授权。验证方式：
- 执行
nginx -V，输出中应包含nginx-plus或built by nginx.com - 检查
/etc/nginx/nginx.conf是否已加载ngx_http_upstream_least_time_module（通常默认启用） - 访问 Nginx 官方文档 least_time 章节，注意标注为 “Available in NGINX Plus only”
least_time 的三种响应时间模式
least_time 支持三个子参数，决定“最快”的计算依据：
- connect：仅统计 TCP 连接建立耗时（最轻量，适合网络波动大但后端处理稳定场景）
- header：统计到收到响应头为止（含 connect + write + first-byte read），反映首字节延迟（TTFB），适合关注用户首屏体验
- last_byte：统计完整响应传输完成（含 connect + write + full read），反映整体响应耗时，适合大文件或长请求
例如：least_time header; 表示优先选 TTFB 最低的服务器。
基本 upstream 配置示例
在 http 块中定义 upstream，并指定算法与参数：
upstream backend {
least_time header;
server 192.168.1.10:8080;
server 192.168.1.11:8080;
server 192.168.1.12:8080;
}
⚠️ 注意事项：
- 必须搭配
keepalive使用以提升测量准确性（建议keepalive 32;） - 不支持与
weight混用（权重会被忽略） - 建议开启
slow_start=30s避免新上线节点因历史无数据被误判为“最快” - 可配合
max_fails=2 fail_timeout=30s实现基础健康检查
监控与调优建议
Nginx Plus 提供实时指标接口（/api/5/upstreams），可查看各 server 的 response_time、response_time_in_seconds 等字段。日常运维建议：
- 定期抓取 API 数据，绘制各节点响应时间趋势图，识别慢节点
- 若某节点长期响应时间异常低，需排查是否因故障未返回完整响应（如提前断连），此时
last_byte比header更可靠 - 避免在高并发突增时立即切流，可通过
queue 100 timeout=5s;缓冲请求，防止雪崩
