这个坑值得记一笔。推理服务用 httpx 设了 timeout=Timeout(60)，长文档摘要经常在 60 秒整抛 ReadTimeout，服务端日志显示首 token 在 88 秒才产出，之后每秒都有输出。
刚开始盯着「重试把同一条长请求又发一遍 加重排队」，折腾了半个多小时，排掉了。
把日志和配置对完，能解释这个现象的基本就这几处。总超时和读间隔没分开 两个值混用；首包慢是排队造成的 不是生成慢；网关的 idle timeout 比客户端更短。
上来先把连接、读、总超时分开设置
python -c "import httpx;print(httpx.Timeout(connect=5,read=120,write=10,pool=5))"量一次首包与总耗时
curl -N -o /dev/null -w '%{time_starttransfer}' https://api.example.com/stream然后对长请求单独放宽读超时
python client.py --read-timeout 180 --only-long同步调大网关的空闲超时
nginx -T 2>&1 | Select-String proxy_read_timeout我习惯把每一步的执行时间和结果记在一边，后面复盘省事。
怎么算真的好了，看的是同一批现象。长请求完成率回到 100%，ReadTimeout 只在真的没有任何输出时出现，重试次数明显下降。
读超时管的是两次数据之间的间隔，总超时才是整段上限，混用会一边误杀一边漏杀。报错文案容易误导，真正的原因往往在相邻那一层的日志里。