least_time header;实现基于TTFB的智能分流，统计从请求发起至收到响应头的时间，真实反映首屏加载延迟；需配合keepalive 32;、proxy_buffering off;及后端及时flush，并通过$upstream_header_time日志验证效果。
直接在 upstream 块中配置 least_time header; 即可实现基于 TTFB 的智能分流。它会让 Nginx 每次选那个“首字节返回最快”的后端，而不是平均响应时间最短或连接数最少的——这对用户首屏体验提升最直接。
为什么选 header 而不是 connect 或 last_byte
header 模式统计的是从发起请求到收到响应头（即 TTFB）的时间，包含 TCP 连接、请求发送、服务端处理、首字节生成与返回全过程。它真实反映用户等待“页面开始加载”的延迟：
- connect 只看建连耗时，忽略后端业务逻辑，容易误判（比如某台机器网络好但数据库卡死）
- last_byte 包含整个响应体传输，对大文件有用，但会掩盖首屏慢的问题（例如后端 200ms 返回 header，却花 3s 才发完 body，TTFB 已超标）
- header 是 Web API 和 SSR 页面的核心瓶颈所在，也是 Lighthouse、Web Vitals 等工具重点监控的指标
配套必须开启的 Nginx 设置
单独写 least_time header; 不够，还需确保以下三点生效，否则 TTFB 分流效果会打折甚至失效：
- 启用
keepalive连接池：keepalive 32;放在 upstream 内，避免每次新建连接干扰 TTFB 测量 - 关闭缓冲干扰：
proxy_buffering off;在 location 中设置，防止 Nginx 缓存响应头再统一发出 - 确保后端真正“早 flush”：如果应用层（如 Express/Next.js）没在生成
后立刻res.flush()，Nginx 就收不到真正的首字节，测出来的 TTFB 就是假的
怎么验证是否生效
不能只看配置语法对不对，要确认 Nginx 真正在按 TTFB 做决策：
- 开启 Nginx 的 upstream 日志：
log_format upstream '$upstream_addr $upstream_response_time $upstream_header_time';，其中$upstream_header_time就是实际测量出的 TTFB（单位秒，精度毫秒） - 用 curl -w "@format.txt" 发起多次请求，观察不同后端的
time_header是否明显差异，且流量是否倾向数值更低的节点 - 人工制造一台后端 TTFB 偏高（比如加个 500ms sleep），看流量是否快速切走——这是 least_time 动态性的关键体现
注意和 ssl_buffer_size 的协同
如果用了 HTTPS，ssl_buffer_size 会影响首字节封装发出的时机。默认 4KB 可能让小响应（如 JSON API）卡住不发；建议对 API 类服务设为 ssl_buffer_size 1k;，让 TLS 记录更早成型并推送，使 measured TTFB 更贴近真实服务端行为。但不要无脑调小，大 HTML 页面保持 4k 更省开销。
