DeepSeek API 请求超时：连接、读取与流式中断排查

先画出请求时间线

以同一 UTC 时钟记录 DNS、TCP/TLS 连接、写入完成、首字节、每次流事件、最后字节和客户端取消时间。结合 HTTP 状态、模型、stream 开关、代理节点和 request ID（如有）判断真正的失败阶段。没有这条时间线，“请求超时”无法区分上游排队与本地读取策略。

DeepSeek 的保活与流式解析

DeepSeek 文档说明，等待调度时非流式请求会持续返回空行，SSE 会返回 : keep-alive 注释，以减少 TCP 空闲中断风险。手写解析器应按 SSE 帧边界处理事件、忽略保活注释，并在收到完整结束事件前把结果保持为未完成；不得对每个数据片段单独 JSON.parse。

连接、读取与总预算

分别设置连接、读取空闲和整个业务请求的截止时间，并使反向代理与应用的预算一致。总预算应覆盖排队和生成，而不是只看 socket 已连接。若代理先超时，客户端可能只能看到中断；用短输入、不同 stream 模式和同环境最小请求比对，确定责任层。

出错后的有限恢复

500 和 503 属于官方错误码表中的服务端问题，可在短暂等待后受控重试；网络中断或客户端超时不证明服务端完全没有执行。读取类操作通常较易重放，而计费、写入或带工具副作用的流程应使用幂等键或状态查询。

记录: connect_ms, ttfb_ms, total_ms, stream, status
仅在 operation_id 未完成且重试预算尚余时重新提交

何时升级问题

如果同环境最小请求在多个时间窗口持续断开，或错误伴随服务端 5xx/503，保存脱敏时间线、模型、API 路径、客户端与代理版本后联系服务方。不要为了测试而关闭 TLS 校验、公开密钥或无限延长超时。

持续收到空行或 : keep-alive 是故障吗？

不一定。DeepSeek 文档说明它会在等待调度时发送非流式空行或 SSE keep-alive，以避免 TCP 因空闲超时中断。

超时后能否直接重发？

先确认请求是否可能已被服务端执行。读取类请求风险较低；会产生计费、写入或外部副作用的流程需要幂等键或结果查询。