deepseek messages transport failed 与流式断流怎么区分：五分钟分诊与取证

20 毫秒就失败，和 20 秒后断流，是两种病；把它们都叫 transport failed，就会用错药。 DeepSeek Harness 里 DeepSeek Messages transport failed（code: TRANSPORT）是传输层的兜底标签，只要失败没能归入空闲超时、主动取消或已有的 LlmError，就会被包成它（源码）。所以真正要回答的不是「为什么报 TRANSPORT」，而是「这次请求到底走到哪一步」。这篇按分诊表走，不重复讲传输层兜底机制本身。

先看错误码：DeepSeek Harness 里 TRANSPORT、超时与 401/400 各指向什么

错误码决定排查方向：TRANSPORT 是未归类，TIMEOUT 是流太久没新分片，401/400 是业务或凭据拒绝。 先对号，再决定要不要重试。

1. 先在日志里找这一轮的 turn/end 记录，确认外层 code。
2. 外层是 TRANSPORT 时，展开 cause，看里面的原始 code。
3. 外层是 TIMEOUT 或 ABORTED 时，不要再按 transport 排查。
4. 外层是 401 / 400 时，去查凭据与请求参数，而不是网络。
5. 把 code 与 cause 一起记下来，别只抄一句文案。

错误码是分诊的入口，不是结论。TRANSPORT 只说明「没能归类」，它下面的 cause 才是身份；401/400 本来就不该长成 transport failed，如果长成了，说明请求还没走到应用层就被拦了。

流式断流的三个现场特征：DSH plugin 环境也要算变量

流式断流的典型现场是「已经输出一部分、然后停住」，不是「一开始就没动静」。 三个特征同时出现，方向基本锁在连接或代理。

1. 内容已经输出一段，突然停在中途，没有正常收尾。
2. 请求状态是 200，但流没有正常结束，客户端等不到最后一帧。
3. 日志里先有流式事件，随后出现连接错误或重试记录。

环境变更也要算进来：最近换了代理、装了抓包工具、升级了插件或改了网络，都可能是断流的起点。插件本身不一定有错，但它改变了请求链路，排查时不能只看模型侧。相邻的 TLS 重签问题见 杀软 TLS 证书链报错。

五分钟分诊顺序：DeepSeek Harness 先分清「没发出」与「发到一半」

五分钟够做一次分诊：01 分钟看 code，12 分钟看请求数，23 分钟看端点返回码，35 分钟读 cause 与决定动作。 顺序固定，避免一上来就换网络。

# 1) 本地有没有代理在拦
env | grep -i -E 'https?_proxy|no_proxy'
# 2) 直连模型端点，看连接与返回码（地址换成你的提供方基础地址）
curl -sS -o /dev/null \
  -w 'HTTP %{http_code}  连接 %{time_connect}s  总耗时 %{time_total}s\n' \
  https://api.deepseek.com/v1/models

1. 0~1 分钟：确认外层 code 是 TRANSPORT、TIMEOUT 还是 401/400。
2. 1~2 分钟：看这次请求有没有发出；请求数为 0 就是本地准备阶段。
3. 2~3 分钟：看端点返回码，200 说明通了，401/403 说明被拒。
4. 3~4 分钟：读 cause 与最后一条流式事件，判断断点位置。
5. 4~5 分钟：决定重试、续跑还是先修环境；只做一次决定，不反复试。

「请求发没发出」是信息量最大的一条判据。请求数为 0、失败在几十毫秒量级，通常是本地准备失败；请求已发出、流到一半才断，才是连接层。两类问题的修法完全不同。

重试前先问一句

这次失败是确定性的，还是偶发的？

1. 每次都在同一位置失败：确定性错误，先修再重试。
2. 换个时间就正常：偶发，记录时间点后观察。
3. 只在特定网络或代理下失败：环境相关，先换链路验证。

取证清单：DeepSeek Harness 日志里该抄哪五样

取证抄五样：时间、code 与 cause、请求数、端点返回码、最后一条流式事件；再加一条环境变更。 五样齐了，问题基本能落到某一层。

1. 发生时间，精确到分钟，方便与其他日志对齐。
2. 外层 code 与 cause 里的原始 code，两个都记。
3. 这次请求有没有发出，以及失败耗时量级。
4. 端点最近一次返回码。
5. 最后一条流式事件是什么，之后还有没有重试记录。

第六样是环境变更：代理、抓包工具、插件增删、版本更新。它不直接解释错误，但能解释「为什么是今天开始」。取证完成后，再决定是重跑、续跑还是提交问题；会话本身不会因为这一轮失败而消失。

与相邻报错区分：什么时候不是 DeepSeek Harness 的 transport 问题

三种情况不该按 transport 排查：凭据或参数被拒、前端连不上宿主、附件对象缺失。 它们的错误码或现场特征都与断流不同。

1. 401 / 400 类：属于 LlmError，带自己的码；去查密钥、模型名与请求参数。
2. 前端连不上宿主：是浏览器与 DeepSeek Harness 之间的通道问题，不是模型请求。
3. 附件缺失：请求数为 0、每次几十毫秒就失败，且该会话每个请求都失败；这是本地准备阶段的问题。
4. 插件导致的环境变化：先回滚最近一次插件变更，再复现，别在变化过的环境里找模型原因。
5. 同字符串不同成因：附件缺失与 TLS 重签都可能落到同一句文案，靠「请求发没发出」分流。

区分的目的不是分类好看，而是让下一步动作有依据。传输层兜底的完整机制见 transport failed 排查，附件缺失的专门场景见 附件缺失导致的 transport failed。