本次提供的来源资料为空，未包含 DeepSeek 官方对超时、重试参数的说明，因此本文不给出任何被表述为官方默认值的数字。以下内容属于服务端集成的工程分析：凡需要在配置文件中填写的秒数、重试次数、可重试状态码白名单，都应以官方文档与自身压测结果为准。

一、超时不是单个参数，而是一条链路
自有服务器调用 DeepSeek API 时，请求至少穿过三段：进程内的 HTTP 客户端、本机或集群中的反向代理（Nginx、Envoy、云负载均衡等）、以及到服务端的公网链路。任何一段先触发超时，整个请求就失败。只调大客户端超时而不动代理，通常无效——代理默认值往往更小，且报错形态不同：客户端看到的是连接被重置或 504，真实原因只在代理日志里。

二、HTTP 客户端层要区分的超时
连接超时（connect）：完成 TCP 与 TLS 握手的时间。公网抖动、DNS 解析慢、出口被限速都会体现在这里，一般设置得比读超时短。
读超时（read）：等待服务端返回字节的时间。要区分“整次请求总时长”与“两次数据到达之间的间隔”两种语义，不同客户端库实现并不一致，配置前需确认自己用的是哪一种。
写超时（write）：发送请求体的时间，长输入场景下不可忽略。
连接池获取超时（pool / acquire）：并发高时线程会卡在等空闲连接上。这个参数若未设置，表现是“程序不报错但请求持续堆积”。
总超时（deadline / overall）：兜底项，应大于前面各项的组合上界。

三、反向代理层
代理层通常有三类关键参数：与上游建立连接的超时、等待上游响应的超时、整个请求的总超时。流式（SSE）响应在这里最容易出问题：若代理的读超时按“整次请求”计时而非“两次数据之间”计时，长回答会在中途被代理切断，客户端只看到流中断。启用流式输出时，代理的响应超时必须与业务侧对单次生成时长的预期对齐，并视情况关闭响应缓冲。

四、重试策略
重试的前提是幂等。可重试范围一般限于连接类失败与明确的限流、服务端错误；而请求已送达、仅响应超时的情况要谨慎——服务端可能已完成生成，重试会造成第二次计费。因此：
只在发送阶段失败（连接未建立、请求体未发出）时做较激进的重试；
读取阶段超时，应结合业务能否容忍重复决策，或用业务侧去重键规避；
使用指数退避加随机抖动，避免故障期间所有实例同步重试；
设置重试预算（总时长上限或次数上限），不要让“单次超时 × 重试次数”变成用户侧可见的卡顿。

五、延迟放大与观测
若单次读超时为 T、最多重试 N 次，最坏情况下用户等待接近 (N+1)×T，再叠加退避间隔。建议给每个请求设置总 deadline，并让每次重试的超时随剩余 deadline 递减，避免重试比首次调用更慢。
观测上至少记录：DNS 与连接耗时、首字节时间、流式场景下的首 token 时间与总时长、每次重试的原因与次数。这些指标能把“网络慢”“代理切流”“服务端排队”区分开。

六、结论
超时与重试应被视为一次端到端的预算分配：客户端、代理、业务总 deadline 三层对齐，重试只在明确安全且不放大延迟的范围内启用。具体数值需以 DeepSeek 官方文档与自身环境压测为准，本文不替代官方参数说明。