least_conn依赖三类超时参数保障调度可靠性：proxy_connect_timeout（建连超时）、proxy_read_timeout（响应超时）、fail_timeout（健康检查超时），需配合proxy_next_upstream实现自动重试，避免单点阻塞。
least_conn 本身不处理超时，但它依赖超时参数来确保连接数统计真实、调度行为可靠。没有合理超时配置，least_conn 很容易误判节点状态——比如一个卡死的连接长期不释放，系统以为它还在“干活”，结果新请求继续被绕开，实际却造成整体响应堆积。
必须配齐的三类超时参数
这三类超时分别作用于不同阶段，缺一不可：
- 连接建立超时（proxy_connect_timeout）：控制 Nginx 与后端建立 TCP 连接的最大等待时间。建议设为 1–3 秒。超时后立即放弃并尝试下一个节点，避免在故障机器上空等。
- 请求转发后等待响应超时（proxy_read_timeout）：决定 Nginx 等待后端返回完整响应的最长时间。应略高于业务 P99 处理耗时（例如 AI 推理设为 120s，报表服务设为 60s）。超时即断开连接，并触发重试逻辑。
- 健康检查失败判定超时（fail_timeout）：配合 max_fails 使用，定义“连续失败多少次、多久内”就将节点临时摘除。常用组合是 max_fails=2 fail_timeout=15s，确保慢节点或假死节点快速退出调度池。
超时要和重试机制联动
单独设 timeout 不够，必须让 Nginx 在超时后主动换节点重试，否则 least_conn 的调度优势会被单点阻塞抵消：
- 在 location 块中加：proxy_next_upstream error timeout http_500 http_502;
- 确保该指令与 proxy_pass 同级，且不能写在 upstream 块里
- 它表示：只要遇到连接错误、响应超时、或返回 500/502，Nginx 就自动把当前请求转给下一个 least_conn 选出的节点
避免超时参数互相干扰
几个常见冲突点要注意：
- proxy_read_timeout 必须大于后端 keep-alive timeout，否则空闲连接可能被后端先关闭，导致 Nginx 统计的“活跃连接数”虚高（连接已断但 Nginx 还没感知）
- keepalive_timeout（server 级）建议设为 65s，比 proxy_read_timeout 小，防止客户端长连接拖慢整体复用效率
- 不要把 proxy_send_timeout 设得过短——它只影响 Nginx 向后端发请求体的过程，对 least_conn 调度几乎无影响，反而易引发误中断
验证超时是否真正起效
别只看配置语法正确，重点观察行为：
- 用 curl -v 模拟慢响应，确认超时后是否跳转到其他节点（看响应头中的 X-Upstream 或日志）
- 压测时开启 stub_status，对比各后端 active connections 和 requests 数值变化趋势——若某节点 active 长期为 0 但 requests 持续上涨，说明超时未触发重试或健康检查未生效
- 查 error.log 是否频繁出现 upstream timed out，这是 proxy_read_timeout 生效的直接证据
