OpenClaw 不回复排障：一次“配置都对但还是超时”的真实复盘

摘要（先看结论）

  • 如果你刚升级过 OpenClaw/Node，且模型直连 curl 能 200，但 OpenClaw 仍然“不回复/超时”：优先跑 openclaw doctor --repair 修复 gateway service（LaunchAgent）不一致
  • 模型是否可用，不用猜：直接 curl 打 .../chat/completions 最快定性（千万别把 API Key 粘贴到日志/群里）
  • “默认模型改了但仍不生效”的常见原因是旧会话/旧 service 仍在用旧配置；doctor 往往能一把把服务态对齐

背景与症状

现象：OpenClaw 发消息后无任何回复或长时间卡住，最终超时。日志里能看到类似：

  • embedded run timeout ... timeoutMs=600000
  • Profile volcengine:default timed out. Trying next account...

我这台机器的真实情况是：同机 curl 调用 Ark 模型能正常 200 返回，但 OpenClaw 仍然“等到超时都不回”。最后通过 openclaw doctor 修复后恢复。

最短排查路线（只做真正能定性的步骤）

  1. 看 OpenClaw 当前“默认模型路由 + 鉴权来源”是否对（openclaw models status）
  2. 用 curl 直连 Ark /chat/completions 定性：是 Key/权限/模型名问题，还是 OpenClaw 服务态问题
  3. 看 logs 抓超时特征（是否出现 service config non-standard、token embed、版本管理器 node 路径等）
  4. 如果你升级过 OpenClaw/Node：直接跑 openclaw doctor --repair 把 LaunchAgent service 对齐

第一步：确认默认模型与鉴权来源（OpenClaw 侧）

命令：

openclaw models status

这次排查时的输出（已脱敏）：

Config        : ~/.openclaw/openclaw.json
Agent dir     : ~/.openclaw/agents/main/agent
Default       : volcengine/kimi-k2.5
Configured models (1): volcengine/kimi-k2.5

Auth overview
Auth store    : ~/.openclaw/agents/main/agent/auth-profiles.json
Shell env     : off
- volcengine effective=profiles:~/.openclaw/agents/main/agent/auth-profiles.json | profiles=1 (oauth=0, token=0, api_key=1) | volcengine:default=(redacted) | models.json=(redacted) | source=models.json: ~/.openclaw/agents/main/agent/models.json

怎么理解：

  • Default：OpenClaw 默认会用哪个 provider/model（没显式指定模型时就用它）
  • Auth store：凭据存在哪（持久化），而不是临时 export 在终端
  • Shell env: off：对 LaunchAgent 场景很关键——后台服务不一定继承你的终端环境变量，不要把希望放在 export ARK_API_KEY=... 上
  • effective/source：最终生效的凭据来自哪里（这里是 profiles/models.json）

结论：从 OpenClaw 自检看，默认模型路由与鉴权来源看起来都没问题。

第二步：用 curl 直连 Ark 定性（排除“模型/Key/网络”）

为什么要做：只靠 OpenClaw 日志，你很容易在“配置/服务/网络/提供方”之间兜圈子。curl 直连能把问题快速砍成两半：

  • curl 都不通：先别怪 OpenClaw
  • curl 能通：优先怀疑 OpenClaw 的 service/会话/配置生效链路

1) 先做一次“空鉴权”的快速验证（看到 401 是正常的）

curl -I --connect-timeout 5 --max-time 10 https://ark.cn-beijing.volces.com/api/coding/v3

HTTP/2 401 + AuthN_MissOrInvalidAuthorizationHeader 这类返回是正常的：没带 Authorization 被拒绝，但能快速响应说明网络至少通。

2) 再做一次“带 Key 的最小请求”（不要输出/传播 Key）

export ARK_API_KEY="你的key"
time curl --connect-timeout 5 --max-time 120 \
  -H "Authorization: Bearer $ARK_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model":"kimi-k2.5","messages":[{"role":"user","content":"ping"}],"max_tokens":16,"stream":false}' \
  https://ark.cn-beijing.volces.com/api/coding/v3/chat/completions

我这次的结果是 200（耗时约 10 秒，上游处理时间约 10.5 秒），说明：

  • Key/权限有效
  • 模型名可用（kimi-k2.5）
  • 网络链路可用

结论：如果你也能 200，但 OpenClaw 仍然“不回复/超时”，问题基本就不在 Ark 本身了。

第三步：看日志抓“服务态不一致”信号

命令：

openclaw logs --follow

这次排查里真正关键的日志片段（已脱敏）：

embedded run timeout: ... timeoutMs=600000
Profile volcengine:default timed out. Trying next account...

Service config looks out of date or non-standard.
Gateway service embeds OPENCLAW_GATEWAY_TOKEN and should be reinstalled.
Gateway service uses Node from a version manager; it can break after upgrades.
Recommendation: run "openclaw doctor" (or "openclaw doctor --repair").

怎么理解：

  • timeoutMs=600000：不是“立刻报错”，而是请求一路等到 10 分钟才超时，很像 service/会话/调用链卡住
  • service config out of date / embeds token / node from version manager：典型“升级后后台 LaunchAgent 仍在用旧配置或易碎路径”，CLI 看到的配置与 service 实际运行态可能不一致

如果你觉得 10 分钟太久，可以把 OpenClaw 的默认 run 超时调小（例如 180 秒）。这是“更快失败”的手段，不解决根因，但能显著降低排障等待成本：

openclaw config file

在配置里加入/修改：

{
  "agents": {
    "defaults": {
      "timeoutSeconds": 180
    }
  }
}

应用并验证：

openclaw config validate
openclaw gateway restart

第四步：一键修复（openclaw doctor --repair）

当你满足这些条件时，优先跑 doctor：

  • 本机升级过 OpenClaw/Node
  • openclaw config validate 通过、openclaw models status 看起来也对
  • 同机 curl 调模型能 200
  • 但 OpenClaw 仍然“不回复/超时”

执行：

openclaw doctor
openclaw doctor --repair

doctor 过程中会出现类似交互：

  • Archive orphan transcript file(s)：归档孤儿会话记录（不是删除，属于清理残留）
  • Update gateway service config to the recommended defaults now?：把 gateway LaunchAgent service 配置更新为推荐默认值（等价于把服务态重新对齐）

我这次选择接受修复后，OpenClaw 恢复正常回复。

后续验证：

openclaw gateway restart
openclaw gateway probe
openclaw status

根因复盘（为什么 “curl 能 200” 但 OpenClaw 会超时）

这次最像的根因是：OpenClaw CLI 侧的配置/模型已经对齐，但后台 gateway service（LaunchAgent）在升级后处于“非推荐/过时/不一致”的运行态。

典型表现：

  • service 内嵌旧 token 或使用非标准 service 配置
  • service 使用版本管理器（如 nvm）下的 node 路径，升级后容易漂移
  • 导致“你以为在用的新配置/新模型/新 key”，实际 service 还在用旧环境，最终表现为长时间等待直到超时

这里的 service token 指的是：gateway 作为后台服务运行时，会要求本机客户端在连接时携带一个“访问令牌”，用来做最基本的访问控制（避免本机任意进程都能连上控制面/执行工具）。

为什么会成为坑：

  • token 可能被“写死/内嵌”在 LaunchAgent 的 service 配置里（例如 plist 的环境变量/启动参数），升级或重装后你在配置文件里更新了 token，但后台服务仍按旧 token 运行
  • 最终表现通常不是清晰的 401，而是客户端与服务端握手/鉴权不一致导致的各种异常（例如连接失败、行为不符合预期、甚至看起来像卡住）

解决思路：

  • 让 service 配置与当前推荐默认值对齐（openclaw doctor --repair 会做这件事）
  • 必要时强制重装 gateway service（doctor 过程中会提示类似“update gateway service config to recommended defaults”）

openclaw doctor --repair 本质上是在把这些“服务态”统一回推荐默认值，让 CLI 与后台 service 对齐，所以一把就好了。

Logo
龙虾开发者社区

小龙虾开发者社区是 CSDN 旗下专注 OpenClaw 生态的官方阵地，聚焦技能开发、插件实践与部署教程，为开发者提供可直接落地的方案、工具与交流平台，助力高效构建与落地 AI 应用

更多推荐

学生党福音：OpenClaw+nanobot搭建学习监督助手

本文介绍了如何在星图GPU平台上自动化部署🐈 nanobot：超轻量级OpenClaw镜像，构建智能学习监督助手。该方案利用轻量级模型实现网课进度跟踪、自动生成练习题和错题整理功能，特别适合学生群体通过QQ机器人实现移动端学习管理，显著提升学习效率。

avatar 龙虾开发者社区

OpenClaw+GLM-4.7-Flash语音交互：对接Whisper实现语音控制

本文介绍了如何在星图GPU平台上自动化部署【ollama】GLM-4.7-Flash镜像，构建语音交互系统。该系统结合Whisper语音识别与GLM-4.7-Flash的指令理解能力，实现智能家居控制等场景的语音操作，提升日常任务执行效率。

avatar 龙虾开发者社区

OpenClaw创意工坊：用nanobot镜像生成技术海报文案

本文介绍了如何在星图GPU平台上自动化部署🐈 nanobot：超轻量级OpenClaw镜像，快速生成技术海报文案。该镜像基于Qwen3-4B模型，能将复杂技术术语转化为通俗表达，适用于技术活动宣传、社交媒体推广等场景，显著提升内容创作效率。

avatar 龙虾开发者社区