# Claude Code 报错 Connection closed mid-response：实测日志对照

> 新版叫 Connection lost mid-response：完整的块保留，最后一块丢弃，写完的工具调用照常执行。先核对改动再 continue，反复出现看 debug 日志。

- URL: https://blog.laozhang.ai/zh/posts/claude-code-connection-closed-mid-response
- Published: 2026-10-21
- Updated: 2026-10-21
- Author: LaoZhang AI Team (https://blog.laozhang.ai/zh/about)
- Topic: Claude Code
- Tags: Claude Code, Connection closed mid-response, Connection lost mid-response, API Error, 故障排查

---
`API Error: Connection closed mid-response. The response above may be incomplete.` 是 Claude Code 2.1.227 之前的文案；从 2.1.227 起，同一种情况显示为 `API Error: Connection lost mid-response. The response above may be incomplete.`。两者意思相同：回答写到一半，承载流式响应的连接断了。断开前已经完整写出的文字块和工具调用都会保留，写完的工具调用还会照常执行；正在写的最后一块被丢弃。Claude Code 在这个阶段故意不自动重发请求，因为重发可能把同一批工具调用再执行一遍。

所以处理顺序是：先确认哪些文件改动和命令已经生效，再回复 `continue`；同一会话反复出现时，打开 debug 日志找到断开的那一行，按原因只修一处：升级版本、换网络对照、检查代理或网关、排查安全软件、处理第三方端点的版本问题，或者防止电脑睡眠。后面的日志对照来自 Claude Code 2.1.306 上的一次本地模拟复现，测了什么、没测什么都在那一节写明。

## Connection closed 与 lost mid-response：同一报错，断在回答中途

[Claude Code 官方错误参考](https://code.claude.com/docs/zh-CN/errors)把这条提示归在"The response above may be incomplete"一节。它只在一种时机出现：Claude 已经完成了一个文字块或一个工具调用（或者思考结束后已经开始写其中一种），回答还没结束，连接就出了问题。断开的时机不同，你看到的东西也不同：

- **还没完成任何内容就断开**：Claude Code 自动重试，最多 10 次，指数退避。界面上是 `Retrying in Ns · attempt x/y` 倒计时，不是这条提示。
- **思考已结束、还没开始写文字或工具调用时断开**：快速重发最多 2 次，仍然断开就以 `Connection lost before a response was produced` 结束本轮。
- **已经完成一个文字块或工具调用后断开**：保留已完成的部分，显示本提示，不重发。
- **回答已经完整结束后才断开**：从 2.1.222 起直接忽略，本轮正常结束。2.1.222 之前的版本会在这种情况下误报 `Connection closed mid-response`，回答其实是完整的。

![一次回答的时间线：四个断开时机分别对应自动重试、快速重发、显示 Connection lost mid-response 和正常结束](https://blog.laozhang.ai/posts/zh/claude-code-connection-closed-mid-response/img/disconnect-timing.webp)

同一节还列了 6 个变体，屏幕上是哪一个，就已经说明了断开的类型：

| 屏幕上的变体 | 官方给出的含义 | 旧版本的表现 |
| --- | --- | --- |
| `Connection lost mid-response` | 连接断开；代理或网关在回答结束前"正常"关闭响应体，也显示这一条 | 2.1.227 之前叫 `Connection closed mid-response` |
| `The response stopped arriving` | 连接还开着，但不再有数据，流式空闲看门狗（idle watchdog）把它中止了 | 2.1.227 之前叫 `Response stalled mid-stream` |
| `Server error mid-response` | 回答中途收到过载或 5xx 服务器错误 | 2.1.199 之前整轮报错，已输出的部分不保留 |
| `Your computer went to sleep mid-response` | 回答传输期间电脑进入睡眠，唤醒后连接按断开处理 | — |
| `Part of the response never arrived` | API 和 Claude Code 之间丢了一个流事件 | 2.1.281 之前显示 `API Error: Content block not found` |
| `The response stream was malformed` | 收到已结束内容块的事件，或事件本身损坏 | — |

"重试"和"续写"要分清：重试是把同一个请求重新发一遍，只在还没有任何完整内容时才做；续写是在保留已完成内容的基础上让 Claude 接着写，需要你发 `continue`，或者由非交互模式自动触发。

## 回复 continue 之前：先核对已经执行的文件改动和命令

交互会话里，提示上方留下的内容就是 Claude 已经完成的部分，最后几句话或最后一个工具调用可能缺失。问题在于，已经写完的工具调用会被执行，Claude Code 还会从这些结果继续本轮。长任务做到一半断开时，文件可能已经改了，命令可能已经跑了。

1. 先看文件状态：在项目目录里运行 `git status` 和 `git diff`，确认哪些文件已经被改过。
2. 再看有副作用的命令：安装依赖、数据库迁移、`git push`、部署、发消息一类操作，去对应的地方核对它到底执行了没有，不要只看对话记录。
3. 回复 `continue`。如果第 2 步发现某个操作已经完成，在同一条消息里写明"迁移已经执行过，不要再跑"，避免 Claude 按自己的记录重做。
4. 同一会话里第二、第三次出现，就不再是偶发，按后面的日志对照排查。

恢复会话和核对已完成操作的完整做法，可以参考 [Claude Code API Error 500 怎么办：恢复原会话，不重做已完成操作](https://blog.laozhang.ai/zh/posts/claude-code-500-529-rate-limit)，中途失败后的处理思路是一样的。

## claude -p、Agent SDK 和 CI：自动续写 3 次后退出码为 1

非交互模式的处理方式不同。官方文档写明，在 `-p` 运行、Agent SDK 和云端会话里，如果被截断的回答在主对话中、包含文字但没有工具调用，Claude Code 会保留已输出部分并自动让 Claude 续写，最多连续 3 次；3 次都用完仍然断开，才显示这条提示。这个行为从 2.1.246 开始，子代理（不论会话是否交互）从 2.1.257 开始也会自动续写。自动续写只针对包含文字、没有工具调用的截断回答；含工具调用时，Claude Code 照常执行已写完的工具调用，再从结果继续本轮。

本地模拟复现的观察和文档一致：每次流式响应都在第二个文字块中途断开，`claude -p` 一共发出 4 个请求（首次加 3 次续写），每次请求里的消息数依次是 2、4、6、8；随后进程退出，退出码为 1，耗时约 2 秒。

需要注意 stdout 里有什么：默认的 text 输出只打印**最后一个完整的文字块**，再接上这条提示。模拟测试里 stdout 只有第 4 次请求的那一段，前 3 次续写写出的文字没有出现在 stdout 里。2.1.219 之前更糟，text 输出只打印提示本身，已经生成的回答全部丢掉。用 `--output-format json` 或 `stream-json` 时，这条提示放在 `result` 字段里。

在脚本和 CI 里，这意味着：

- 退出码 1 时，不要把 stdout 当成完整结果使用。
- 解析 json 输出的流程要检查 `result` 是否是这条提示，而不是只看有没有内容。
- 网络稳定后，恢复同一会话再发一次 `continue`：

```bash
# 继续当前目录最近的一次会话
claude --continue -p "continue"

# 或者按会话 ID 恢复
claude --resume "$SESSION_ID" -p "continue"
```

## 本地模拟复现：每种断开在 debug 日志里留下的那一行

同样显示 `Connection lost mid-response`，背后可能是连接被重置，也可能是中间某一层把响应提前"正常"结束了，屏幕文案分不出来，debug 日志可以。下面是一次可重复的本地模拟，用来对照每种断开在日志里的特征。

测试条件：Claude Code 2.1.306 原生版，macOS；一个用 Python 写的 Anthropic 兼容模拟服务器监听在 `127.0.0.1`，`ANTHROPIC_BASE_URL` 指向它；用的是假 key，不调用真实 API，没有费用。命令是 `claude -p "Say hello"` 加 `--debug-file`。每次流式响应都先发一个完整的文字块，再开始第二个文字块，然后按下表的方式中断：

| 模拟的故障 | 屏幕上的结果 | debug 日志里的关键行 | 退出码 / 耗时 |
| --- | --- | --- | --- |
| 第二块写到一半，服务器发送 TCP RST | `Connection lost mid-response` | `[WARN] Stream connection closed (ECONNRESET) after 1 block(s) yielded — finalizing partial response` | 1 / 2 秒 |
| 响应体正常结束，但没有 `message_stop` | `Connection lost mid-response` | `[ERROR] Stream ended cleanly inside open block 1 (stop_reason=null) — treating as a dropped connection`，接着是 `Stream connection closed (StreamTruncated)` | 1 / 2 秒 |
| 中途发送 `overloaded_error` 事件 | `Server error mid-response` | `[WARN] Mid-stream server error after 1 block(s) yielded — finalizing partial response` | 1 / 2 秒 |
| 连接保持打开但不再发数据，设 `CLAUDE_BYTE_STREAM_IDLE_TIMEOUT_MS=10000` | `The response stopped arriving` | `[ERROR] Streaming idle timeout (byte-level): stream idle: no bytes for 10000ms, aborting stream` 和 `[byte-watchdog] firing` | 1 / 41 秒 |
| 只发出 `message_start` 就发送 RST，设 `CLAUDE_CODE_MAX_RETRIES=2` | 没有报错，正常输出 | 两次 `Stream connection error (ECONNRESET) — retrying streaming`，然后 `Error streaming, falling back to non-streaming mode` | 0 / 3 秒 |

停顿那一行耗时 41 秒，是因为 4 个请求各自等满 10 秒的字节级超时。

从这张表可以读出三件事：

- **同一个 `Connection lost mid-response`，日志分得出两种原因。** `ECONNRESET` 表示连接被重置，发出重置的可能是本机网络栈、VPN、运营商线路上的设备，也可能是服务端；`StreamTruncated` 表示连接链路上的某一层把响应体干净地结束了，通常要查反向代理、网关或本地转发工具。
- **很多 ECONNRESET 你根本看不到。** 在任何内容完成之前断开，Claude Code 会静默重试，最后改用非流式请求，模拟测试里这次请求最终成功，屏幕上没有任何报错。界面上 `attempt x/10` 的计数一直涨，就是断在这个阶段。
- **`The response stopped arriving` 和 `Connection lost mid-response` 是两类问题。** 前者是连接没断但没数据，和超时设置有关；后者是连接确实断了或被提前结束，调超时没有用。

![屏幕提示与 debug 日志关键行对照：ECONNRESET、StreamTruncated、字节级空闲超时和中途服务器错误各自的原因与排查方向](https://blog.laozhang.ai/posts/zh/claude-code-connection-closed-mid-response/img/debug-log-map.webp)

在自己的环境里拿到同样的日志：

```bash
# 启动时把 debug 日志写到文件（也可以用 claude --debug）
claude --debug-file ~/claude-debug.log

# 报错复现后，筛出和流式断开有关的行
grep -E "Stream connection|Stream ended cleanly|Mid-stream server error|idle timeout|byte-watchdog|retrying streaming|non-streaming" ~/claude-debug.log
```

这次复现没有覆盖的部分：模拟服务器不是真实的 Anthropic API，也没有制造真实的网络故障；只测了 `-p` 的 text 输出，交互模式下的显示以官方文档为准；没有测 2.1.227 之前的版本，旧版的日志措辞可能不同（GitHub 上 2.1.224 用户贴出的日志里，`Stream connection error (ECONNRESET) — retrying streaming (1/10)` 格式相同）；睡眠、丢事件、事件损坏这三个变体没有模拟。

## 先看版本号：低于 2.1.222 会误报，之后几版持续修过这条路径

运行 `claude --version` 看当前版本，`claude update` 升级（安装方式不同时的升级办法见 [Claude Code 安装教程：全平台完整设置指南（2026）](https://blog.laozhang.ai/zh/posts/claude-code-install)）。屏幕上还是 `Connection closed mid-response` 的旧文案，就说明版本低于 2.1.227，先升级再排查，能省掉一部分已经修好的问题。截至 2026 年 10 月 21 日，最新版本是 2.1.306，[Claude Code CHANGELOG](https://github.com/anthropics/claude-code/blob/main/CHANGELOG.md) 里和这条报错直接相关的修复有：

| 版本 | 变化 |
| --- | --- |
| 2.1.199 | 中途的服务器错误保留已输出部分，显示 `Server error mid-response` |
| 2.1.214 | Windows 企业代理断开隧道导致的 `Socket is closed` 开始重试 |
| 2.1.219 | `claude -p` 的 text 输出不再丢掉已经生成的回答 |
| 2.1.222 | 回答已经完整时不再误报 `Connection closed mid-response`；自定义 `ANTHROPIC_BASE_URL` 网关在保活心跳正常到达时不再误触发空闲超时 |
| 2.1.227 | 文案改为 `Connection lost mid-response` 和 `The response stopped arriving` |
| 2.1.232 | Bedrock、Vertex 和网关部署上的流式空闲超时可以恢复，不再直接让请求失败 |
| 2.1.246 | `-p`、SDK、云端会话自动续写被截断的回答 |
| 2.1.257 | 子代理被截断后自动续写 |
| 2.1.281 | 代理丢掉流事件时保留部分回答，不再报 `Content block not found` |
| 2.1.284 | 回答中途断开后的重试和本次请求的其他重试共用一个预算，持续失败时更早放弃 |
| 2.1.288 | 回答中途的 API 超时在非交互会话和子代理里改为续写 |
| 2.1.290 | Bedrock、Vertex、Foundry 和自定义网关上，被电脑睡眠打断的回答不再被当成停顿 |

例外是走第三方 Anthropic 兼容端点的用户：社区报告的问题恰好出在 2.1.221 之后，见后面单独一节。

## 日志里是 ECONNRESET：换网络对照，再查 VPN 和安全软件

连接被重置时，先做一次对照，比直接改配置更快定位：

- **换手机热点跑同一个任务。** 热点下正常、家里或公司网络下断开，问题就在原来那条线路或线路上的设备。GitHub 上有西班牙、波兰的用户报告过特定运营商线路上的重置，测到和数据包大小、路径 MTU 有关，用 VPN 或手机热点就正常；这类问题多数表现为还没输出就 `Connection dropped (ECONNRESET)`，并不专门出现在回答中途，但热点对照同样能把它分出来。
- **看多个会话是不是同一秒报错。** 一位用户发现，不同项目、不同版本的会话总在一个 5 分钟周期的同一秒出错，最后查到是路由器的 WAN 连接每 300 秒掉线 1 到 2 秒，NAT 被重置，正在接收的流式回答被悄悄断掉；他看到的是 `The response stopped arriving`。多个会话同时出错，说明问题在它们共用的东西上：路由器、VPN、代理，或者服务端。

**中国大陆 + 全局 VPN。** 一份 GitHub 报告（Windows，2.1.223）描述的现象是：小请求正常，请求体达到约 100 KB 以上就反复 `ECONNRESET` 或 `Connection closed mid-response`，而且一阵一阵的。真实的交互会话带着项目上下文和历史，很容易超过这个大小，所以表现为"短问题能答，干活就断"。评论里有人给出的做法是在 `~/.claude/settings.json` 的 `env` 里把代理直接指向 VPN 客户端的本地代理端口，让 Claude Code 自己走代理，而不是依赖全局隧道：

```json
{
  "env": {
    "HTTP_PROXY": "http://127.0.0.1:你的本地代理端口",
    "HTTPS_PROXY": "http://127.0.0.1:你的本地代理端口"
  }
}
```

这是单个评论者的做法，原 issue 已因长期无活动被关闭，效果没有官方确认。代理、证书和 `NO_PROXY` 的完整配置，以及连接根本建立不起来时怎么查，见 [Claude Code Unable to connect to API：ECONNREFUSED、ECONNRESET 与代理错误排查](https://blog.laozhang.ai/zh/posts/claude-api-error-connection-error)。

**Windows 上的 Winsock 残留。** 一位用户在 [GitHub issue #84211](https://github.com/anthropics/claude-code/issues/84211) 里用对照表排除了 IPv6、VPN、MTU 等因素，最后发现是已卸载的网络加速器留下的 Winsock LSP：2.1.220 正常，2.1.221 起几乎每个请求都 `ECONNRESET` 或 `Connection closed mid-response`，执行 `netsh winsock reset` 并重启后恢复。后续评论里又有 Proxifier、MaLion 两款软件出现同样情况。动手前先用 `netsh winsock show catalog` 看有没有非系统的条目；`netsh winsock reset` 会重置所有第三方 Winsock 组件，依赖它的 VPN 或加速软件之后可能需要重新安装。

**企业电脑上的 EDR 和 HTTPS 检查。** 另一份报告来自装了 WithSecure Elements Agent 的公司 Windows 电脑：公司网络、家里 Wi-Fi、手机热点下 CLI 和 VS Code 插件都反复报 `Connection closed mid-response`，同一台电脑上浏览器里的 claude.ai 却完全正常。报告者推测是安全软件在检查长时间的流式连接。换任何网络都断、只有 Claude Code 断，就值得请 IT 看一下终端安全软件的 HTTPS 检查和例外设置。走企业代理时报 `Socket is closed` 的，官方说明最常见的原因是 Windows 企业代理断开了已建立的隧道，2.1.214 起会重试，先升级。

## 日志里是 StreamTruncated 或 stopped arriving：代理、网关和超时设置

**`StreamTruncated`：响应体被中间层提前结束。** 官方对 `Connection lost mid-response` 的说明里专门提到，代理或网关在回答结束前"正常"关闭响应体也显示这一条。连接没有被重置，而是某一层认为响应已经结束了。走自建网关、Nginx 一类反向代理、或者 CC Switch 这样的本地转发工具时，先绕过它直连一次做对照；确认是它之后，检查它对单个响应的最长时长、读取超时和响应缓冲设置（Nginx 里对应 `proxy_read_timeout`、`proxy_buffering` 等指令），让长时间的流式响应能完整透传。`ANTHROPIC_BASE_URL` 和 settings.json `env` 应该写在哪里，见 [Claude Code API 配置：先选路由，再设置 Key、模型和网关](https://blog.laozhang.ai/zh/posts/claude-code-api-configuration)。

**`The response stopped arriving`：连接还在，数据不来了。** 字节级看门狗在一段时间内收不到任何字节（包括保活心跳）就中止连接。按 [Claude Code 网络配置文档](https://code.claude.com/docs/en/network-config#streaming-idle-watchdogs)，默认时长是：直连 Anthropic API 180 秒；Claude Platform on AWS、Amazon Bedrock 和自定义 `ANTHROPIC_BASE_URL` 300 秒。调整用这两个变量：

- `CLAUDE_STREAM_IDLE_TIMEOUT_MS`：同时设事件级和字节级看门狗，低于 5 分钟的值会被提到 5 分钟，字节级上限 30 分钟。
- `CLAUDE_BYTE_STREAM_IDLE_TIMEOUT_MS`：只设字节级看门狗，范围 10 秒到 30 分钟。

调大只在一种情况下有用：你的网关会把整段响应攒起来再发，或者确实会长时间不发字节。如果是路由器、NAT 或运营商把连接悄悄断了，数据永远不会再来，调大只是让你等得更久才看到报错。另外，2.1.222 之前自定义网关在心跳正常到达时也可能误报这一条，版本过旧先升级。

**`API_TIMEOUT_MS` 管不到这里。** 它限制的是等待响应头的时间，不是响应头到达后流式传输能持续多久，对 `Connection lost mid-response` 和 `The response stopped arriving` 都没有作用。它对应的是另一种报错：一直等不到响应开始，提示 `No response from API`。

## 走 DeepSeek、通义千问等第三方端点：2.1.221–2.1.229 的回归报告

`ANTHROPIC_BASE_URL` 指向第三方 Anthropic 兼容端点时，有一组集中的社区报告。博客园 2026 年 8 月 22 日的一篇文章记录：Claude Code 2.1.229 配 DeepSeek 官方 API（`https://api.deepseek.com/anthropic`），先出现 `Connection dropped (ECONNRESET)` 的重试计数，重试 10 次后要么成功（耗时超过 3 分 20 秒），要么以 `Connection lost mid-response` 结束；作者说 DeepSeek、阿里千问、讯飞 MaaS 等端点都有这个问题。GitHub 上 2.1.222 到 2.1.224 的报告是同一形态：首个数据块约 400 毫秒到达，随后几秒内连接被重置，每个流式请求都这样，非流式请求正常，同一台机器换回 2.1.220 就好。

这些报告被合并到 [GitHub issue #84404](https://github.com/anthropics/claude-code/issues/84404)，该 issue 已于 2026 年 10 月 2 日以 not planned 关闭；截至 2.1.306，CHANGELOG 里没有对应的修复条目。真实第三方端点在当前版本上是否仍有这个问题，公开资料里没有结论，前面的模拟测试也没有覆盖。

报告者普遍的做法是降级到 2.1.220 并设 `DISABLE_AUTOUPDATER=1` 关闭自动更新（博客园文章用的是 `npm install -g @anthropic-ai/claude-code@2.1.220`）。这是权宜之计，代价是失去上面版本表里 2.1.222 之后的全部修复：完整回答被误报、网关空闲超时误触发、非交互自动续写、子代理续写，都会回到旧行为。比较稳妥的顺序是：

1. 先在当前版本上开 debug 日志复现，确认是"每个流式请求在首个数据块后不久就 ECONNRESET"这一形态，而不是偶发断开。
2. 把同样的日志发给端点服务商，问他们是否已知这个问题。
3. 需要马上恢复工作时再降级，并记下降级版本，Claude Code 或端点更新后重新测一次当前版本。

第三方路线本身的配置和首个报错怎么查，见 [Claude Code 连接 OpenRouter 和 DeepSeek：路线选择、配置与首错排查](https://blog.laozhang.ai/zh/posts/claude-code-openrouter-deepseek)。

## Your computer went to sleep mid-response：长任务挂机时防止 Mac 睡眠

这个变体的原因写在文案里：回答传输期间电脑睡眠了。一份 GitHub 报告描述了它在无人值守时的放大效应：Mac 每隔约 15 分钟进入闲置睡眠，三个后台代理的回答一次次被截断，每次唤醒后重写整轮，持续了约 6 个小时，消耗了大量 token 却没有产出。

评论里给出的临时做法是在另一个终端里为当前的 `claude` 进程持有一个防睡眠断言：

```bash
caffeinate -i -w "$(pgrep -nx claude)"
```

`-i` 阻止闲置睡眠，`-w` 在这个 `claude` 进程退出时自动释放。它对用电池时合上盖子无效，那种情况 macOS 仍会睡眠。2.1.290 修复了 Bedrock、Vertex、Foundry 和自定义网关上把睡眠中断误判成停顿的问题，同一版本也修了 Mac 唤醒后后台代理报 "Agent stalled" 的问题。

## 不在本地的迹象，以及向官方反馈时要带的证据

偶尔出现一次不代表本机有问题。一位用户统计了自己机器上 130,204 次 API 响应（2.1.220，没有代理和 VPN），2026 年 7 月 29 日之后约 1% 以 `Connection closed mid-response` 结束（全部历史约 0.16%）。这只是一台机器的数据，但说明健康网络下也会碰到。一次 `continue` 就能接上，没必要为它改配置。

下面这些迹象出现时，更可能不是你本地能修的问题，可以停止反复改设置：

- 换手机热点、换另一台电脑后照样出现，而且日志是 `ECONNRESET`。
- 不同仓库的多个会话在同一毫秒报错，同时排除了路由器周期性掉线。
- [Claude 状态页](https://status.claude.com/)上有事故。
- 屏幕上是 `Server error mid-response`：这是服务端返回了过载或 5xx，等一会儿或换模型，见 [Claude Code 报 529 过载怎么办：换模型还是等待](https://blog.laozhang.ai/zh/posts/claude-code-overloaded-error)。

2026 年 10 月 16 日到 17 日，GitHub 上有用户报告一台 Mac 上多个并发会话集中掉线：7 天记录到 291 次，其中 276 次落在 16 日和 17 日，以 `Connection lost mid-response` 和 `The response stopped arriving` 为主，经常是不同仓库在同一毫秒出错；另一位 Linux 用户（2.1.302，官方 API）用抓包对上了 debug 日志里的 `ECONNRESET`，重置包来自 `160.79.104.10`（`api.anthropic.com` 的地址）。截至 2026 年 10 月 21 日，官方在这两个 issue 里没有回应，这只能当作用户报告看待。

到 [anthropics/claude-code 的 GitHub issue 列表](https://github.com/anthropics/claude-code/issues)反馈时，带上这些能让问题被定位：

- `claude --version` 的输出和操作系统。
- 你走的路线：订阅登录直连、API key 直连、Bedrock 或 Vertex、自建网关、第三方端点，以及中间有没有 VPN 或代理。
- 屏幕上的报错原文。
- debug 日志摘录：`[API REQUEST]` 那一行（含 `x-client-request-id`）、首字节时间、断开那一行，删掉会话内容。
- 出错的时间点（注明时区），以及是否有多个会话同时出错。
- 热点对照、绕过代理对照的结果。

## 常见问题

### Claude Code 一直 retrying 后报 Connection lost，怎么回事？

`attempt x/10` 计数在涨，说明连接在任何内容完成之前就断了，Claude Code 在自动重试；如果中间某次已经写完了一个文字块再断开，就会以 `Connection lost mid-response` 结束。每次请求都在开头不久被重置，最常见于走第三方端点的 2.1.221–2.1.229 回归报告、Windows 上的 Winsock 残留，或者某条线路本身的问题。用 debug 日志里的 `retrying streaming` 行确认，再按上面对应的一节处理。

### 调大 API_TIMEOUT_MS 能解决 Connection closed mid-response 吗？

不能。`API_TIMEOUT_MS` 只限制等待响应头的时间，响应开始后的流式传输不受它影响。连接被重置的 `Connection lost mid-response` 调什么超时都没用；只有 `The response stopped arriving`，而且网关确实会长时间不发数据时，调大 `CLAUDE_STREAM_IDLE_TIMEOUT_MS` 或 `CLAUDE_BYTE_STREAM_IDLE_TIMEOUT_MS` 才有意义。

### 新开会话两三句就报 Connection closed，/compact 也没用？

几乎每个请求都断时，问题通常不在上下文长度上，压缩会话不会改变连接被重置这件事。更值得查的是路线和本机网络栈：走 DeepSeek 等第三方端点且版本在 2.1.221 之后的回归报告、Windows 上残留的 Winsock 组件，以及全局 VPN 下请求体一大就断的报告，都是"短问题能答、干活就断"的形态。先看版本号，再开 debug 日志看断开那一行。

## 参考来源

本文引用的外部页面，按正文出现顺序排列。最后更新于 2026-10-21。

- [Claude Code 官方错误参考](https://code.claude.com/docs/zh-CN/errors) (code.claude.com)
- [Claude Code CHANGELOG](https://github.com/anthropics/claude-code/blob/main/CHANGELOG.md) (github.com)
- [GitHub issue #84211](https://github.com/anthropics/claude-code/issues/84211) (github.com)
- [Claude Code 网络配置文档](https://code.claude.com/docs/en/network-config) (code.claude.com)
- [GitHub issue #84404](https://github.com/anthropics/claude-code/issues/84404) (github.com)
- [Claude 状态页](https://status.claude.com/) (status.claude.com)
- [anthropics/claude-code 的 GitHub issue 列表](https://github.com/anthropics/claude-code/issues) (github.com)