Claude Code 流式响应中断怎么办？Connection closed、Socket is closed、Stream idle timeout 三条分开看
正看着它一行行往外写，突然停了，下面来一句：
API Error: Connection closed mid-response. The response above may be incomplete.
或者：
Socket is closed
再或者：
API Error: Stream idle timeout - partial response received
这三条都属于「流中断」——响应还在传的时候连接断了。但它们的处置很不一样：有一条有明确的版本修复，有一条有官方的恢复方法，还有一条到核对日为止仍然没有公认解法。
分开看，别一锅烩。
一、Socket is closed：这条有明确的版本修复
官方说明的成因：流式响应的连接在响应还在到达时被关闭了。
官方处理：
- 更新到 v2.1.214 或更高版本：
claude update - 重新发送消息
- 如果在同一个代理后面持续失败，去查网络配置
第一条是这三条报错里唯一一个明确的版本修复。所以撞上 Socket is closed，第一件事不是排查网络，是看看自己的版本。
claude update
这条的性价比极高——如果你的版本低于 v2.1.214，很可能一条命令就解决了，不用往下折腾。
二、The response above may be incomplete：能恢复，别重来
官方说明的成因：流式请求在响应中途失败了，但 Claude 已经完成了一部分文本或工具调用。
关键在后半句：它已经做了一部分。 所以正确的处理不是重发原始请求（那等于把已经做完的又做一遍），而是让它接着做。
官方处理：
- 交互式会话：把屏幕上剩下的响应读完，然后回复
continue - 非交互模式（
-p）：用--output-format json或stream-json，从结果字段里看它到底完成到哪了
第一条那句「把屏幕上剩下的响应读完」值得留意——中断之前的内容是有效的，不是废的。你先看它做到哪一步了，再决定 continue 还是换个说法重新指挥。
第二条对自动化很重要。非交互模式下你看不到「屏幕上的内容」，必须靠结构化输出。如果你的脚本只捕获纯文本，遇到中断就分不清是完成了还是断了——换成 json 或 stream-json，结果字段会告诉你。
三、Connection closed mid-response：仍无定论
这条对应 issue #69415（仍开放）。它的报错文本和上一条的后半句是同一个：
API Error: Connection closed mid-response. The response above may be incomplete.
所以官方 errors 页对「The response above may be incomplete」给的处理，对它是适用的——交互式回 continue，非交互用结构化输出。
但 issue 里反映的是更严重的情况：频繁到影响正常使用。那条 issue 到核对日为止没有公认的根因和解法，评论区基本是同样遭遇的汇报。
有一条评论提供了有价值的排除信息：虽然这条 issue 被打了 platform:wsl 标签，但在 macOS 直连的环境下同样复现。 也就是说，它不是 WSL 或 Windows 专属的问题——如果你在 macOS 上撞到，不用怀疑自己看错了标签。
评论区还提到一个场景值得单独说：在自动接受 / 无人值守模式下，这条报错格外难受。整个模式的意义就是让它自己跑完多步骤任务，一次中途断流就把流程停在那，需要人回来敲 continue——等于把无人值守变成了有人值守。
如果你在跑这类任务，实际能做的：
- 任务切小。断在第 3 步和断在第 30 步，恢复成本差很远
- 非交互模式用
--output-format json或stream-json，让脚本能判断出「断了」而不是「跑完了」 - 检查
CLAUDE_CODE_RETRY_WATCHDOG——官方对无人值守会话的建议是设为1
四、Stream idle timeout：也没有定论
对应 issue #46987（仍开放，184 条评论）。报错是：
API Error: Stream idle timeout - partial response received
这条 issue 里没有公认解法，评论多是同样的遭遇汇报。所以本文不给「解法」，只给判断方法。
怎么判断这次是不是普遍问题：
- 看时间集中度。如果是某一段时间里密集出现、过后又好了，多半是服务端侧的短时状况
- 换网络试一次。换个网络环境仍然复现，基本可以排除本地网络
- 查 status.claude.com。有故障公告就不用查自己了；没有也不代表没问题（短时状况不一定上状态页）
能做的调整：
API_TIMEOUT_MS 默认是 600000 毫秒（10 分钟），可以调高。但要说清楚：这是针对「超时」的旋钮，而 idle timeout 说的是「流空闲了」——两者不完全是一回事，调它有没有用要自己试。本文不承诺它有效。
五、四条对照表
| 报错 | 确定性 | 第一步 |
|---|---|---|
Socket is closed | 官方有明确修复 | claude update 到 v2.1.214 或更高 |
The response above may be incomplete | 官方有恢复方法 | 交互式回 continue；非交互用 --output-format json |
Connection closed mid-response（频繁） | 仍无定论（issue #69415） | 按上一条恢复；任务切小；已知不是 WSL 专属 |
Stream idle timeout | 仍无定论（issue #46987） | 判断是否服务端短时状况；换网络验证 |
六、几条能减少损失的习惯
流中断这类问题，很多时候你控制不了它发不发生，但能控制它发生时你损失多少。
任务切小。 这是唯一一条对四种情况都有效的。一次跑八个步骤，断在第七步，前面六步的成果可能还在，但你得花时间确认；一次跑两个步骤，断了重来的成本很低。
中断后先看，别急着重发。 官方那句「把屏幕上剩下的响应读完」是有道理的——中断前它可能已经改了文件、执行了命令。直接重发一遍原始请求，可能会重复执行。先看做到哪了，再决定。
非交互场景一律用结构化输出。 --output-format json 或 stream-json。这是唯一能让脚本分清「完成」和「中断」的办法。
无人值守任务设 CLAUDE_CODE_RETRY_WATCHDOG=1。 这是官方对这类场景的建议。
版本别落太远。 四条里已经有一条（Socket is closed）是靠版本修的。落后几个版本，可能在解决一个已经被修掉的问题。
七、子代理里断流，报的是另一条
如果中断发生在子代理里，你在主会话看到的不是上面那几条，而是：
Agent terminated early due to an API error
官方给的处理是两步：
- 把错误详情对到错误参考页里相应的那一节
- 底层错误解决之后，要求 Claude 重试任务或者恢复子代理
第一步的意思是：这条报错本身不是一种故障类型，它是个信封——真正的错误在里面，可能是本文讲的流中断，也可能是限流、认证、输出上限。拆开看，然后按里面那条的办法治。
第二步「恢复子代理」值得记住：不必从头再派一次任务。 底层问题解决后可以接着做。这在子代理已经跑了很久的时候能省不少事。
八、还有一种「看起来断了其实没断」
顺带说一个容易误判的情况，避免你把它当成流中断去排查。
官方排查页里提到：Markdown 表格超过 200 行时，只会渲染前 200 行，然后显示一句 … N more rows not shown。
这看起来很像「输出被截断了」，但官方明确写了：只是显示被限制，完整表格仍然在对话里，用 /copy 会复制全部行。
判断方法很简单：看有没有那句 … N more rows not shown。 有，就是显示上限，不是中断；没有而且内容明显不完整，才往流中断的方向查。
如果确实需要看完整的大表格，官方给的建议是让它写到文件里，而不是在终端里渲染。
（另外，官方提到在 v2.1.208 之前是渲染全部行的，所以恢复一个包含超大表格的会话时可能会卡在重新渲染上——这也是一个「看起来挂了其实是在渲染」的情况。）
九、总结
- 先看是哪一条：
Socket is closed有版本修复，优先claude update。 The response above may be incomplete是可恢复的——回continue，不要重发。- 另外两条到核对日仍无公认解法，能做的是判断和减损，不是修复。
Connection closed mid-response不是 WSL 专属，macOS 直连同样复现。- 无论哪一条，任务切小 + 非交互用结构化输出都能显著降低损失。
本文所引官方内容来自 Claude Code 官方错误参考文档，issue 编号来自 anthropics/claude-code 仓库（#69415、#46987 核对日仍为开放状态），核对日 2026-08-08。版本号与产品行为会变化，以官方文档为准。