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

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

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

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

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

命令：

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

怎么理解：

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

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

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

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

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

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

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

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

• Key/权限有效
• 模型名可用（）
• 网络链路可用

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

命令：

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

怎么理解：

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

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

在配置里加入/修改：

应用并验证：

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

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

执行：

过程中会出现类似交互：

• ：归档孤儿会话记录（不是删除，属于清理残留）
• ：把 gateway LaunchAgent service 配置更新为推荐默认值（等价于把服务态重新对齐）

我这次选择接受修复后，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 配置与当前推荐默认值对齐（ 会做这件事）
• 必要时强制重装 gateway service（doctor 过程中会提示类似“update gateway service config to recommended defaults”）

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