least_time算法通过持续测量动态选择响应最短节点，其“最快”由connect（仅tcp连接）、header（ttfb，推荐web api）或last_byte（全响应体）三种模式定义，需配置keepalive且禁用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; 缓冲请求，防止“争抢最快节点”引发雪崩
