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

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 官方错误参考把这条提示归在"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，回答其实是完整的。

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

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

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

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

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

恢复会话和核对已完成操作的完整做法，可以参考 Claude Code API Error 500 怎么办：恢复原会话，不重做已完成操作，中途失败后的处理思路是一样的。

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：

# 继续当前目录最近的一次会话
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。每次流式响应都先发一个完整的文字块，再开始第二个文字块，然后按下表的方式中断：

停顿那一行耗时 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 日志写到文件（也可以用 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））。屏幕上还是 Connection closed mid-response 的旧文案，就说明版本低于 2.1.227，先升级再排查，能省掉一部分已经修好的问题。截至 2026 年 10 月 21 日，最新版本是 2.1.306，Claude Code CHANGELOG 里和这条报错直接相关的修复有：

例外是走第三方 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 自己走代理，而不是依赖全局隧道：

{
  "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 与代理错误排查。

Windows 上的 Winsock 残留。 一位用户在 GitHub issue #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、模型和网关。

The response stopped arriving：连接还在，数据不来了。 字节级看门狗在一段时间内收不到任何字节（包括保活心跳）就中止连接。按 Claude Code 网络配置文档，默认时长是：直连 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，该 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：路线选择、配置与首错排查。

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

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

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

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 状态页上有事故。
• 屏幕上是 Server error mid-response：这是服务端返回了过载或 5xx，等一会儿或换模型，见 Claude Code 报 529 过载怎么办：换模型还是等待。

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 列表反馈时，带上这些能让问题被定位：

• 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 日志看断开那一行。