症状
流式请求在接收部分响应后突然中断，客户端表现为：
- 输出内容在句子中间戛然而止，未收到正常的流结束标记（如
[DONE]或finish_reason: stop）。 - 连接层面出现
SSE connection closed、stream reset或ECONNRESET错误。 - 部分请求可以正常完成，中断呈间歇性发生。
常见原因
- 网络中间件超时：反向代理（Nginx、Cloudflare）的读超时或空闲超时设置过短，在模型生成较慢时主动断开连接。
- 客户端读取超时：HTTP 客户端库的 read timeout 配置不足以覆盖模型推理的全部耗时。
- 供应商侧负载均衡：供应商的服务节点在高负载时主动回收长连接。
- 响应体过大：请求生成的总输出 Token 极大，传输过程中触发了数据大小限制。
排查步骤
- 检查客户端 HTTP 库的
read_timeout和connect_timeout配置，流式请求的读超时建议设为 300 秒以上。 - 如果使用了 Nginx 反向代理，确认以下配置项：
proxy_read_timeout 300s、proxy_send_timeout 300s、proxy_buffering off。 - 在客户端实现流式重连机制：当检测到非正常断开时，记录已接收的内容位置，携带续传标记发起新请求。
- 通过网络抓包工具（如 tcpdump 或 Wireshark）分析断开发生在哪一层——TCP RST 来自客户端还是服务端。
- 减小单次请求的
max_tokens参数，确认是否因输出长度过大触发了断开。
预防
- 在网络链路的每一层（客户端、代理、CDN）统一配置足够长的超时时间。
- 实现应用层心跳检测，定期发送 ping 保持连接活跃。
- 在客户端缓存已接收的流式片段，中断后可从断点继续，避免完全丢失已生成的内容。
- 对于关键业务场景，提供流式与非流式的降级切换——当流式连续失败时自动切换为非流式调用。