Nginx stream模块不支持least_time算法，因其工作在四层，无法获取应用层响应耗时；可用least_conn、一致性哈希、ip_hash或权重+健康检查等替代方案实现低延迟优化。
Nginx stream 模块不支持 least_time 算法——这是 HTTP 模块（http/upstream）中 ngx_http_upstream_module 提供的高级负载均衡策略，依赖于对 HTTP 响应头或完整响应体的时序测量，而 stream 模块工作在四层（TCP/UDP），不解析、不拦截、不等待应用层数据，因此无法获取 SQL 响应耗时、Redis 命令返回时间等指标。
所以，直接在 stream 的 upstream 块中写 least_time header 或 least_time last_byte 会导致配置加载失败（Nginx 启动报错：unknown directive "least_time"），或被静默忽略（取决于版本），起不到任何延迟优化作用。
真正适用于数据库 TCP 代理、能降低感知延迟的替代方案如下：
least_conn
优先将新连接分发给当前活跃连接数最少的后端。对长连接密集型数据库（如 MySQL 连接池复用场景）非常有效，可避免某节点因连接堆积导致响应变慢。hash $remote_addr consistent
对客户端 IP 做一致性哈希，使同一客户端长期固定连接到同一后端。减少连接抖动和 SSL/TLS 握手开销，提升复用率与稳定性；配合连接池使用，间接缩短首次查询延迟。ip_hash（仅 IPv4）
简单哈希，适合小规模、IP 相对固定的内网环境，但扩容缩容时映射易失衡，不如consistent健壮。-
手动权重 + 健康感知调度（需外部协同）
stream 本身不提供动态权重调整，但可通过以下方式近似实现“低延迟优先”：- 使用
max_fails=1 fail_timeout=10s快速剔除高延迟节点（表现为建连超时或握手失败） - 配合外部健康检查脚本（如定期
mysqladmin ping+ RTT 测量），自动重写stream.conf并nginx -s reload - 给性能更强的节点设更高
weight（如server 10.0.1.10:3306 weight=3;）
- 使用
关键配置示例（MySQL 场景）：
stream {
upstream mysql_cluster {
least_conn;
zone tcp_mem 64k;
server 10.0.1.10:3306 weight=2 max_fails=2 fail_timeout=5s;
server 10.0.1.11:3306 weight=1 max_fails=2 fail_timeout=5s;
server 10.0.1.12:3306 backup;
}
server {
listen 3306;
proxy_pass mysql_cluster;
proxy_connect_timeout 2s;
proxy_timeout 1h;
proxy_responses 1; # 等待首个 MySQL 协议响应包再判定成功
so_keepalive on;
}
}⚠️ 注意：
proxy_responses 1是关键——它让 Nginx 在转发连接后，等待后端发出第一个有效响应包（如 MySQL handshake 初始化包）才认为连接就绪，避免把流量打到已卡顿但 TCP 连接仍存活的节点上，比单纯max_fails更贴近“低延迟可用性”。
如果业务对端到端查询延迟极其敏感（如金融交易类），建议在客户端侧做连接级路由（如使用 ProxySQL、MaxScale）或在应用层集成延迟感知逻辑，stream 模块更适合承担稳定、轻量、连接级的流量分发角色。
