least_time header; 实现基于实时首字节延迟（TTFB）的调度，需搭配keepalive长连接、禁用weight、配置slow_start与健康检查，并通过$upstream_header_time或Nginx Plus API监控验证。
直接在 upstream 块中使用 least_time header; 即可实现基于最小首字节延迟（TTFB）的调度。它不是“平均值”，而是每轮请求实时选取当前历史 TTFB 最低的后端节点，前提是该节点健康且有长连接支撑。
必须启用 keepalive 长连接
least_time header 依赖真实、稳定的连接复用才能准确测量首字节时间。若未开启长连接，每次请求都新建 TCP 连接，连接耗时会严重干扰 header 时间统计，导致调度失真。
- 在 upstream 块内添加
keepalive 32;（数值按并发量调整，建议 16–100） - 对应 location 中需设置
proxy_http_version 1.1;和proxy_set_header Connection '';，确保 HTTP/1.1 长连接透传 - 不支持与
weight混用——权重会被忽略，只按实测 header 时间排序
正确写法示例（含健康检查）
以下是一个生产可用的配置片段，已包含基础容错和冷启动保护：
least_time header;
keepalive 32;
server 192.168.1.10:8080 max_fails=2 fail_timeout=30s slow_start=30s;
server 192.168.1.11:8080 max_fails=2 fail_timeout=30s slow_start=30s;
server 192.168.1.12:8080 max_fails=2 fail_timeout=30s slow_start=30s;
}
-
slow_start=30s防止新节点刚上线时因无历史响应数据被误判为“最快”，从而承受突发流量 -
max_fails和fail_timeout是必要配套，避免持续将请求发给已异常但 header 仍可能快速返回 502 的节点 - 所有 server 行不能带
weight，否则 least_time 不生效
验证与监控关键点
配置生效后，需通过日志或接口确认是否真正按首字节延迟调度：
- 在 access_log 中启用
$upstream_header_time变量，例如：log_format full '$remote_addr - $upstream_header_time $upstream_response_time'; - 观察日志中同一客户端多次请求是否倾向落在
$upstream_header_time更低的 IP 上 - Nginx Plus 用户可调用
/api/5/upstreams接口，查看各节点的response_time_in_seconds字段趋势 - 若某节点
header极低但last_byte波动大或错误率高，说明它可能丢包、代理截断或后端提前退出，需排查网络或服务稳定性
注意常见误判场景
首字节快 ≠ 后端健康。以下情况会导致 least_time header 调度失效或反效果：
- 后端超时后主动关闭连接，Nginx 可能收到空响应或 502，此时
$upstream_header_time极小但请求实际失败 - HTTPS 场景下，
$upstream_header_time包含 TLS 握手开销，若后端 TLS 配置差异大（如密钥交换慢），会影响公平性 - 后端启用了 gzip 或流式响应，首字节返回早但主体处理未完成，此时更适合用
least_time last_byte配合业务语义判断
