超时链是什么
超时要逐层对齐：客户端超时不应短于网关读超时，网关读超时不应短于引擎单请求的最长生成时间。任何一层偏短，长输出都会在中途被切断，而且各层表现不同——客户端报超时、网关记上游超时、流式场景表现为「说到一半断流」。排查这类问题，先把各层配置对齐再谈调参。
基本信息
| 层次 | 客户端读超时、网关读超时、引擎单请求处理时间 |
|---|---|
| 建议关系 | 客户端 ≥ 网关 ≥ 单请求最长生成时间 |
| 超时类型 | 连接超时与读超时要分开设置，不要用一个值 |
| 取值依据 | 业务最长输出对应的生成时间，而不是习惯性的 30 秒 |
| 复核时机 | 新增代理、CDN 或服务网格后重新核算 |
典型使用场景
- 长输出业务：按最长的输出长度推算需要多大的读超时
- 流式断流排查：确认是超时到点还是中间层缓冲导致连接空闲被断
- 链路变更：接入新的代理层或换成容器网关后，重新核对各层取值
- 压测复现：用最长输出的真实请求验证超时是否够用
- 成本权衡：超时值越大，被中断的请求越少，但异常连接占用资源的时间也越长
三层对照与客户端设置
三层对照与客户端设置
客户端 timeout ≥ 600s
网关 proxy_read_timeout ≥ 600s
引擎生成本身 按业务最长输出评估
（数值为示例：按自身业务最长输出推算，不要照抄）客户端侧写法
客户端侧写法
from openai import OpenAI
# 读超时按最长生成时间设置，连接超时可另外单独控制
client = OpenAI(base_url="http://<网关地址>/v1", api_key="<KEY>", timeout=600.0)
# 校验：用一条长输出请求跑通，确认中途不被切断各层偏短的后果
| 层 | 配置项 | 偏短的后果 |
|---|---|---|
| 客户端 | 请求读取超时 | 长回答被本地放弃，服务侧仍在算 |
| 网关 | 上游读取超时 | 长回答在中途被切断，返回上游超时错误 |
| 引擎与业务 | 单请求生成时间上限 | 输出被截断，业务侧拿到不完整内容 |
| 链路中间层 | 空闲连接与缓冲策略 | 流式数据被攒住，体验与超时同时变差 |
用业务最长输出定上限，而不是拍一个 30 秒；连接建立慢的场景可以用更短的连接超时单独控制，避免把读超时也一起压短。
链路上限取各层最小值：任何一层偏短都会成为实际瓶颈，配置看起来都很大并不代表生效值是大的。