Cline 本地模型五分钟超时怎么修

核心结论

Cline 连接 LM Studio、Ollama 或本地 OpenAI 兼容服务时，如果模型在输出首个字节前长时间计算，旧版本可能在服务端仍正常推理时抛出 terminated: BodyTimeoutError: Body Timeout Error (UND_ERR_BODY_TIMEOUT)。Cline 4.1.25 已修复这条路径：当提供商属于 LM Studio、Ollama、OpenAI Compatible 或 LiteLLM，且基础地址指向本机或本地网络时，客户端会关闭 Undici 的 headersTimeout 与 bodyTimeout；远程 API 和公网网关仍使用原来的超时与代理处理。

因此，这不是把所有请求都改成“永不超时”，也不是简单把五分钟改成更大的固定值。修复的关键是区分本地推理与远程服务：本地模型的首字节等待可能很长，但用户仍可通过 Cline 的停止操作触发 AbortSignal；远程端点则继续保留死连接上限，避免真正失联的请求无限占用资源。遇到类似现象时，可以先参考站内的 LLM 流式输出工程排查，再从模型与平台目录核对自己连接的是本地服务、局域网网关还是公网 API。

报错为什么总在长任务上出现

截至 2026 年 10 月 19 日，Undici 的 Client 文档把 bodyTimeout 定义为“接收正文时，相邻正文数据块之间允许等待的时间”，默认值为 300e3 毫秒，也就是三十万毫秒；headersTimeout 的默认值同样是 300e3 毫秒。文档还明确说明，把这两个值设为 0 可以关闭对应计时。这里监控的是网络线上是否收到字节，不是模型进程有没有占用 GPU，也不是服务端日志有没有继续增长。

这一区别正是故障的根源。大型本地模型处理长提示词时，HTTP 连接可能已经建立，服务端也可能已经收到请求，但在提示词预填充完成、首个流式片段发出之前，网络连接上暂时没有新的正文数据。只要这段无字节时间跨过 Undici 的默认上限，客户端就会主动终止响应。对 Cline 来说，最后看到的是 UND_ERR_BODY_TIMEOUT；对 LM Studio 来说，表现却是客户端先断开，随后服务端停止仍在进行的生成。

Cline 的原始问题记录提供了这条因果链。报告者使用 Cline 4.1.11 与 LM Studio，模型仍持续生成时，Cline 先报 BodyTimeoutError，而 LM Studio 日志随后记录客户端断开并停止生成。这个顺序能排除“本地模型先崩溃，Cline 才收到错误”的解释。它也说明只看 IDE 里的最后一行报错不够，排查时必须把 Cline 时间线与模型服务端日志对齐。

还要避免把这类超时与整段响应总耗时混为一谈。bodyTimeout 关注的是相邻数据块之间的空闲间隔。如果模型已经稳定地持续发送流式数据，计时会围绕数据块间隔工作；最危险的阶段反而可能是首个可见 token 之前的长时间预填充，或者流中某一次长暂停。单纯看到“任务执行了五分钟”并不能证明根因，必须确认错误码、端点类型以及服务端在断开前是否仍有活动。

4.1.25 具体改了什么

Cline 4.1.25 的发布说明把修复描述得很明确：对 LM Studio 和 Ollama 的长请求，不再因为五分钟没有网络数据就以 terminated: BodyTimeoutError 结束。对应合并请求进一步给出了实现边界，修复覆盖 VS Code 扩展与 JetBrains 插件使用的代码路径；CLI、桌面端和 Hub 使用 Bun，不属于这次问题描述中的受影响路径。

代码没有修改全局 fetch，而是新增了一个专用的 fetchWithoutIdleTimeouts。它直接调用 Undici 的 fetch，并给调度器传入下面这组配置：

const NO_IDLE_TIMEOUTS = {
  headersTimeout: 0,
  bodyTimeout: 0,
}

之所以不用被 VS Code 扩展宿主包装过的全局 fetch，是因为合并请求确认，宿主包装层会替换调用方提供的 dispatcher，导致自定义超时设置丢失。专用请求路径仍把调用方的 AbortSignal 传下去，所以关闭空闲计时不等于删除取消能力：用户点击停止，或者上层主动中止任务，仍可结束请求。

更重要的是，Cline 没有仅凭提供商名称关闭计时。实现先检查提供商是否为 lmstudio、ollama、openai-compatible 或 litellm，再检查 baseUrl 是否属于本地网络。可识别的范围包括回环地址、常见私网网段、链路本地地址、CGNAT 地址段、IPv6 本地地址、单标签主机名，以及以 .local、.localhost 或 .internal 结尾的主机名。未填写基础地址时，也会按这些提供商默认指向本机处理。

这层地址判断解决了一个实际取舍：OpenAI Compatible 与 LiteLLM 既可能连接本机模型，也可能连接公司内外的远程网关。如果只按提供商名称关闭计时，远程请求会失去原有的死连接保护，还可能绕开 VS Code 的代理配置。4.1.25 因而让本地网络端点走无空闲计时的专用请求路径，公网地址和无法解析的地址继续走原有、支持代理的 fetch。

哪些环境仍可能超时

升级后仍有几类边界需要单独判断。

第一，自托管模型如果使用公网主机名或公网 IP，Cline 会把它当作远程网关，继续保留 Undici 的默认空闲计时。合并请求的维护者明确记录了这个取舍。也就是说，“机器是我自己的”不等于“地址会被识别为本地网络”。如果 GPU 服务器通过公开域名暴露，升级后仍看到同一错误，应先确认实际 baseUrl，不要仅凭部署归属判断修复是否生效。

第二，Ollama 还有自己的首响应等待逻辑。合并请求讨论指出，Ollama 路径中的 withOllamaResponseTimeout 仍会控制首个响应头的等待，并可通过相应请求超时配置调整。Cline 关闭 Undici 的 headersTimeout 与 bodyTimeout，并不自动取消应用层另行设置的计时。因此，报错名称如果不是 UND_ERR_BODY_TIMEOUT，或者堆栈指向 Ollama 的请求超时包装，就不应套用同一个结论。

第三，真正的服务端停滞仍需处理。4.1.25 为本地模型取消的是传输层空闲上限，而不是证明模型一定会完成。显存不足、模型进程死锁、服务端队列阻塞、容器资源耗尽，都可能让请求长期没有结果。修复后用户可以用停止按钮结束任务，但生产工作流仍应在更高层配置符合业务需求的总任务时限、取消策略和日志告警。

第四，代理路径不同。修复代码让本地回环地址直接连接，其他本地网络地址使用 Undici 的 EnvHttpProxyAgent，主要读取 http_proxy、https_proxy 与 no_proxy。远程端点则保留 Cline 原有的代理感知请求路径。若团队依赖 VS Code 的 http.proxy 访问一个实际位于公网的 LiteLLM 服务，不应为了躲避超时而把它伪装成本地地址；正确做法是保留远程路径，并在网关或客户端层明确设计可控的超时与心跳。

升级与验证步骤

先确认 VS Code 中实际运行的 Cline 版本。修复进入的是 Cline 4.1.25；如果界面仍显示 4.1.24 或更早版本，应先完成扩展升级并重载扩展宿主。不要只看扩展商店页面，因为本地禁用自动更新、远程开发环境或多套 VS Code 配置都可能让实际加载版本不同。

然后确认提供商与地址。下面这些地址会落入修复面向的本地网络范围：

base_url=http://localhost:1234/v1
base_url=http://127.0.0.1:11434
base_url=http://192.168.1.20:8000/v1
base_url=http://host.docker.internal:1234/v1
base_url=http://gpu-box:8000/v1

而公网地址会继续使用原来的请求路径：

base_url=https://gateway.example.com/v1
base_url=https://8.8.8.8/v1

复现验证时，不必一开始就运行超长编码任务。可以使用一个测试用 OpenAI 兼容服务：立即返回 SSE 响应头，随后保持超过五分钟的静默，再发送一个合法数据片段。Cline 合并请求记录的实测方法就是让伪服务静默三百三十秒，然后继续返回响应；修复分支在 VS Code 与 JetBrains 路径上都能收到结果，而且没有依靠重试掩盖第一次断开。引用这个数字时应注意，它来自 Cline 合并请求截至 2026 年 10 月 19 日公开的测试记录，不代表所有本地模型都需要等待这么久。

验证时至少同时保存三类信息：Cline 的完整错误与时间、模型服务端的请求日志、实际端点地址。若升级前在约五分钟处出现 UND_ERR_BODY_TIMEOUT，服务端在同一时刻记录客户端先断开；升级到 4.1.25 后同一测试可以继续收到响应，就能较有把握地确认命中了这次修复。若升级后仍失败，则按“错误码是否相同、地址是否被识别为本地、是否存在应用层超时”的顺序继续缩小范围。

不要用无限重试代替修复

遇到流式中断时，最容易想到的是自动重试，但这类问题不适合直接用重试覆盖。长提示词的预填充往往是本地推理中代价较高的阶段。客户端在五分钟处主动断开后重新发送同一请求，模型可能从头处理上下文；如果重试策略没有幂等边界，还可能重复执行已经发出的工具调用或文件操作。

更稳妥的分层是：传输层允许本地推理跨过固定空闲窗口，交互层保留用户主动取消，任务层设置可解释的总时限，Agent 层为有副作用的工具建立去重或确认机制。Cline 4.1.25 只完成了第一层与第二层之间的修正，它没有替应用决定一个本地模型任务最多应运行多久。

对远程 API 也不应照搬本地策略。公网连接长时间完全没有字节，既可能是模型计算，也可能是反向代理、负载均衡器或上游连接已经失效。远程链路更适合使用明确的首字节超时、数据块空闲超时、总任务超时和有限重试，并记录提供商请求标识。只有本地服务的执行状态可以从同机或局域网日志中直接核对时，关闭底层固定空闲上限才具有更清晰的可观测性基础。