least_time算法通过持续测量connect、header或last_byte响应时间，动态将请求分发给当前最快节点；需启用keepalive、zone及slow_start，禁用weight，仅nginx plus支持。
使用 least_time 配置可让负载均衡器将请求优先转发给当前响应时间最短的上游服务器，实现基于真实延迟的动态分流。这比简单的轮询或随机更贴近实际性能表现，特别适合后端节点处理能力不均、网络抖动明显或存在慢节点的场景。
least_time 的核心原理与适用前提
least_time 不是静态权重配置，而是持续采集每个 upstream server 的健康探测（health check）或真实请求的响应耗时（如 last_response_time），并基于该指标动态调整分发概率。Nginx Plus 支持该指令，开源版 Nginx 默认不支持，需确认版本或启用商业版模块。
- 依赖主动健康检查（
health_check）或被动指标（如proxy_next_upstream_tries配合日志分析）来获取响应时间数据 - 必须配合
zone指令定义共享内存区域，用于跨 worker 进程同步响应时间统计 - 仅对 HTTP/HTTPS 流量生效，不适用于 TCP/UDP 透传（stream 模块需用其他策略如
least_conn）
基础 least_time 配置示例（Nginx Plus）
以下为典型 upstream 块配置，启用基于响应时间的动态选择：
upstream backend {
zone backend 64k;
least_time last_byte fall=3 rise=2 max_fails=3 fail_timeout=30s;
server 192.168.1.10:8080;
server 192.168.1.11:8080;
server 192.168.1.12:8080;
}
其中：
last_byte 表示以完整响应接收完成时刻计算延迟（推荐）；也可用 first_byte（首字节到达时间，对大文件或流式响应更敏感）
fall/rise 控制健康状态切换阈值
max_fails/fail_timeout 仍参与异常节点熔断，与响应时间策略协同工作
如何验证与调优 least_time 效果
直接观察分发是否“偏向快节点”，不能只看配置是否生效，还需结合监控验证：
- 启用 Nginx Plus 的实时仪表盘（
/status接口），查看各 server 的response_time和requests分布是否呈正相关 - 在 access_log 中添加
$upstream_response_time和$upstream_addr，用日志分析工具统计各节点平均延迟与请求占比 - 人为制造一个节点延迟升高（如加 sleep 或限速），观察流量是否在数秒内明显迁移到其余节点
- 避免设置过短的
fail_timeout，否则可能因瞬时抖动误判节点，建议不低于 15s
常见问题与规避方式
least_time 在实际落地中容易因配置疏漏导致失效或反效果：
-
未启用 zone：会导致每个 worker 独立统计，失去全局一致性，务必声明
zone name size -
混用不兼容指令：如同时配置
weight，Nginx Plus 会忽略 weight，但部分旧版本可能行为异常，建议统一用 least_time 管理优先级 - 缺乏探测机制：若未配 health_check 且无真实流量，响应时间始终为 0，所有请求可能集中到第一个 server —— 应确保有稳定探测或初始流量触发统计
-
忽略首包与全包差异：对首屏敏感业务选
first_byte，对下载/上传类业务选last_byte，不可一概而论
