least_time算法按connect、header、last_byte三种响应时间模式动态选最快节点：connect测tcp建连，header测ttfb（推荐web api），last_byte测完整响应体传输；需启用keepalive和slow_start，不可与weight混用。
least_time 算法不是简单选“快”的服务器，而是持续测量、动态比较、实时响应——它把请求分发给当前响应时间最短的后端节点，但具体“快”指什么，取决于你选的子参数。
三种响应时间模式怎么选
least_time 支持三个关键子参数，它们定义了“最快”到底在量什么：
- connect：只算 TCP 连接建立耗时。适合网络抖动大、后端处理能力稳定（比如纯计算服务）的场景，开销最小
- header：统计到收到响应头为止（TTFB）。包含连接 + 请求发送 + 首字节返回，反映用户首屏加载体验，是大多数 Web API 的推荐选择
- last_byte：统计整个响应体传输完成的时间。适合大文件下载、长轮询或流式接口，能避免因后端提前断连导致的误判
例如，least_time header; 表示每轮调度都挑 TTFB 最低的节点；若发现某台机器 last_byte 明显偏高但 header 很低，可能说明它响应快但带宽或磁盘慢。
基础配置与强制依赖项
必须写在 upstream 块中，且不能和 weight 混用（权重会被忽略）：
upstream backend {
least_time header;
keepalive 32;
server 192.168.1.10:8080 max_fails=2 fail_timeout=30s;
server 192.168.1.11:8080 max_fails=2 fail_timeout=30s;
server 192.168.1.12:8080 max_fails=2 fail_timeout=30s;
}
注意两个硬性要求：
- keepalive 必须开启：不启用长连接，每次新建 TCP 连接都会重置计时起点，测不准真实响应差异
- 新节点建议配 slow_start：如 server ... slow_start=30s;，避免刚上线时因无历史响应数据被默认当成“最快”而瞬间压垮
如何避免被假快误导
响应时间异常低，未必代表健康。比如某节点因超时中断连接，header 可能极快返回 502，但实际没处理完——这时 last_byte 更可靠。
- 日常监控建议接入 Nginx Plus 的 /api/5/upstreams 接口，抓取 response_time_in_seconds 字段趋势
- 若某节点长期 header 耗时显著低于其他节点，但 last_byte 波动剧烈或错误率高，应检查是否丢包、代理截断或后端异常退出
- 突发流量下，可加 queue 100 timeout=5s; 缓冲请求，防止“争抢最快节点”引发雪崩
它和 least_conn 是什么关系
least_conn 关注连接数，适合长连接多、处理时长差异大的场景（如 WebSocket）；least_time 关注响应延迟，适合对首字节或整体耗时敏感的 HTTP 服务。
- 两者不互斥，但 Nginx 原生不支持同时启用。需按业务主目标取舍：要低延迟就选 least_time，要防连接堆积就选 least_conn
- 若后端既有 API 又有长连接服务，建议拆成两个 upstream，分别配置不同算法，再由 location 或 proxy_pass 分流
