OpenClaw 发消息不回复？先找到消息卡在哪一步

OpenClaw 看起来收到了消息，却一直没有回复时，先别重装，也别删除 ~/.openclaw。一个 Telegram、Discord、飞书或 WebChat 渠道不说话，并不能证明整个 OpenClaw 都停了。先记下测试消息发出的时间，打开实时日志，只复现一次，看看消息最先卡在哪一步。

先按下面顺序观察，不要一上来就执行写入修复：

hljs bash复制
openclaw status
openclaw status --all
openclaw gateway probe
openclaw gateway status
openclaw doctor
openclaw channels status --probe
openclaw logs --follow

把 openclaw logs --follow 放在另一个终端窗口，再从原来的渠道发送一条最短测试消息。普通 openclaw doctor 只做报告；openclaw doctor --fix 会修改配置或状态，不属于这一轮观察。

先停在这里：在第一个异常环节还没确定前，不要运行 openclaw doctor --fix，不要把所有服务都重启一遍，也不要重装、轮换全部密钥、清空所有会话或删除 ~/.openclaw。

先把一次“没有回复”变成可核对的记录

排障最怕一句“昨天还好好的，今天不行了”。它没有时间、入口、版本和变化点，任何人接手都只能猜。更有效的记录应该像这样：北京时间 14:32，从 Telegram 私聊发出“只回复 OK”，没有收到回复；同一时间 WebChat 可以正常回答；最后一次变更是上午更新 OpenClaw。

先保存命令归属与版本：

hljs bash复制
which -a openclaw
openclaw --version
openclaw status --all
openclaw doctor

which -a openclaw 很重要。终端里的 CLI、包管理器安装的副本和系统托管的 Gateway 服务，不一定指向同一个可执行文件。你可能已经更新了当前 shell 里的 OpenClaw，但 launchd、systemd 或其他服务仍在启动另一个路径。

同时记下三类信息：

• 影响范围：只有群聊不回，还是私聊、控制台和所有渠道都不回？
• 最后变化：刚更新版本、重启机器、轮换渠道 token、修改白名单、换模型，还是更换 Node/包管理器？
• 准确时间：测试消息、日志错误和服务重启分别发生在什么时候，使用哪个时区？

接着只复现一次。在日志窗口已经打开的情况下，从出问题的原渠道发送最短文本。不要连续发十条“在吗”。连续测试会让时间线混在一起，还可能触发限流、认证锁定或多个并行会话。

观察这条消息属于哪一种：

1. 日志里完全没有入口事件；
2. 有入口事件，但被配对、提及、白名单或权限规则拦下；
3. 已进入模型调用，但提供商返回认证、限流、超时或模型错误；
4. 模型已经完成，但发送回渠道时失败；
5. 日志显示发送成功，客户端却没有看到。

需要把输出交给别人时，先删掉 token、API key、Authorization header、手机号、用户标识、私聊正文和敏感本地路径。保留字段名、时间和错误类型，隐藏值本身。例如写 token: [REDACTED]，不要把整份原始配置直接贴出去。

从第一个失败信号决定排查方向

一条回复要经过多段链路：CLI 能否管理当前实例，Gateway 是否可达，控制台或消息渠道能否把输入送进来，模型能否完成，结果能否再送回原渠道。任何一段失败都可能表现成“没回复”。

OpenClaw 官方故障排查也把状态、Gateway、渠道和实时日志放在快速检查的前面。真正决定下一步的不是“列表里出现几个绿色项”，而是最早缺少哪一项健康证明。

例如，openclaw gateway status 显示 Runtime: running，只能说明托管进程存在。若连接探测仍失败，CLI 实际上还没有证明能连上 Gateway。反过来，如果 Gateway 可达、WebChat 正常，只有某个 Discord 群不回复，重装 Gateway 就不是对症动作。

健康信号也要具体：Gateway 应该能被 probe 到，运行状态与连接探测一致，目标端点符合预期；渠道应通过实际 probe，而不是仅仅存在一段配置；日志在一次控制测试中不应反复出现同一个致命错误。

Gateway 停止、不可达或“在运行但连不上”

只有当 openclaw gateway probe 不可达，或 openclaw gateway status 明确指出运行、连接、配置或端点异常时，才进入 Gateway 分支。先继续读取细节：

hljs bash复制
openclaw gateway probe
openclaw gateway status
openclaw gateway status --deep
openclaw doctor
openclaw logs --follow

官方 Gateway 故障排查里的几种典型信号不能混成一种“重启试试”。

提示必须设置 local mode

如果出现类似 Gateway start blocked: set gateway.mode=local，先确认这台机器本来是不是 Gateway 主机。它若应该本地运行，才修正当前活动配置中的 mode；它若只是远程客户端，强行改为 local 会制造第二个 Gateway，而不是连回原来的实例。

非回环地址没有认证

当 Gateway 拒绝在非 loopback 地址上无认证监听，这是一条安全边界。要么配置预期的认证，要么回到本机监听。不要为了“先启动”而绕过认证，否则可能把控制接口暴露到网络。

EADDRINUSE 或端口已被占用

这说明配置端口已经有进程监听。先确认占用者是不是预期 Gateway、一个旧实例，还是无关服务。随便杀进程或同时修改服务端和客户端端口，会让控制台继续指向旧地址，也会把原本清晰的端口冲突变成多处不一致。

CLI 配置与服务配置不同

Gateway 状态可能显示 CLI 与 service 使用不同配置、profile、状态目录或二进制。此时应先确定实际运行的是哪个服务，再修它的启动定义。仅仅在 shell 里执行一次更新，不能证明托管服务已经使用新版本。

服务端口与客户端目标不同

把 status 显示的实际监听地址与控制台、远程客户端或隧道目标逐一对比。只改那个已经过期的一端，并保留另一端作为已知正确值。两边同时改，修好后也无法确认到底是哪一处导致故障。

完成一个明确修正后，重新运行之前失败的 gateway probe 或 status 检查。只有配置需要重新加载，或已经确认运行的是旧服务时，重启才有意义。重启不能替代“究竟是 mode、认证、端口还是服务归属出错”的判断。

Gateway 正常，只是控制台或某个渠道不说话

Gateway 可达之后，故障范围已经明显缩小。此时要把控制台认证与消息渠道分开，因为它们使用的身份、来源和权限完全不同。

只有控制台打不开、未授权或不停重连

先核对控制台连接的 Gateway URL，是否与 CLI 报告的目标一致。然后在实时日志里寻找来源不允许、设备身份缺失、token 不匹配、重复 unauthorized 或认证锁定。

对应动作应该保持局部：

• URL 错了，只修控制台目标；
• 来源不在允许范围，只加入确实可信且需要的 origin；
• 日志证明 token 不匹配，才更换控制台认证；
• 系统要求设备身份，就完成设备身份流程，而不是关闭这条边界；
• 已经连续认证失败时先停止重试，避免继续触发锁定。

修正后只刷新这个控制台并验证登录。渠道 token 和模型 key 没有经过这条失败链路，不需要跟着一起轮换。

Telegram、Discord、Slack、飞书或 QQ 只有一个不回复

先探测实际账号：

hljs bash复制
openclaw channels status --probe
openclaw pairing list --channel CHANNEL

多账号渠道还要带上对应 account 选择器。随后从那个渠道发一条短消息，把平台返回与同一时间的 OpenClaw 日志对应起来。

• 完全没有入口事件：确认机器人是否真的在目标群/频道、当前 token 是否属于这个账号、webhook 或 polling 是否由预期实例接管。
• 要求 @ 提及：按当前群组规则完成提及，不要因为一次测试没 @ 就关闭所有群的门控。
• 出现待配对请求：批准正确身份的配对，不要直接关闭配对机制。
• 被白名单阻止：确认用户、房间或群标识后，只增加必要对象。
• not_in_channel、missing_scope、Forbidden：补齐错误明确指出的平台成员资格、scope 或权限。
• 401/403：先确认错误来自渠道平台、模型提供商还是 OpenRouter，再处理对应凭证。

中文环境里很容易把“群聊不回”归因于网络或模型，但默认提及门控、群白名单、机器人未加入频道、平台权限缺失都更靠近入口。需要重新做渠道安装和账号绑定时，可查看英文 OpenClaw 消息渠道配置指南；若错误明确是 OpenRouter 403，再进入英文 403 专项排查，不要把所有 403 当成同一个 key 问题。

日志已经收到消息，接下来追模型还是回传

只有入口日志已经出现，模型分支才成立。日志里没有消息，说明模型根本没有拿到这次请求；此时换模型、改 provider key 或清理模型会话都不会修好渠道入口。

确认入口后，按实际顺序追踪：

1. 策略与路由是否接受这条消息；
2. 是否选择了预期提供商与模型；
3. 提供商是否接受认证；
4. 模型调用是否完成；
5. 完成结果是否交给原渠道发送。

不同错误由不同环节负责。401/403 可能是认证、授权、账号访问或模型权限；429 是额度或速率边界；timeout/unavailable 更适合有限重试或已经配置好的后备路线；model not found 或 setup error 要核对模型标识与提供商兼容性。当前模型与提供商行为应以官方 provider 故障排查为准，不要从旧教程复制固定模型表。

如果模型已经完成，但原渠道没有看到答案，就离开模型分支。下一步查回传：平台是否拒绝发送、目标线程是否正确、机器人是否仍有发言权限、内容格式或附件是否超过平台限制。先用纯文本“OK”验证最基本的回传，再测试富文本、文件或线程行为。

两个对照实验可以缩小范围：

• 在另一个已经配置好的入口发送同样的最短文本，判断模型路径能否工作；
• 新建一个测试会话，但保留原会话，判断是否只是一段会话状态异常。

它们只是诊断，不是删除证据的理由。原会话、失败时间和日志还没保存前，不要清空会话或状态目录。

更新后突然不回复，先查“谁在运行”

更新之后最常见的误判是“新版本有 bug”。实际问题也可能是：终端 CLI 已更新，托管服务没更新；配置由更高版本写入，却被旧 CLI 再次修改；插件仍加载旧依赖；旧控制台连接到了新 Gateway。

先保存版本分裂：

hljs bash复制
openclaw update --dry-run
openclaw update status --json
which -a openclaw
openclaw --version
openclaw gateway status --deep
openclaw config get meta.lastTouchedVersion

OpenClaw 更新说明把包替换、Doctor 检查与 Gateway 重启放在一个受控流程里。手工用不同包管理器换掉某个二进制，可能只更新当前 shell，没有更新监督程序实际启动的副本。

按不一致本身做决定：

• 旧 CLI 读取新版本写过的配置：先修 PATH 或安装归属，不让旧 CLI 继续写。
• CLI 与服务来自不同路径：只更新或重装已经确认归属的服务，然后核对它报告的版本。
• 插件更新后加载失败：先记录插件与依赖错误，再做针对性修复和重启，不要删除全部插件。
• 协议或能力不匹配：停止旧客户端/包装器，用兼容版本重新连接，不要强迫新 Gateway 兼容来源不明的旧客户端。
• 版本完全一致但仍不回复：回到正常链路检查。故障发生在更新之后，不等于更新一定是根因。

截至 2026 年 7 月 13 日，GitHub 将 OpenClaw v2026.6.11标为 Latest，发布时间为 6 月 30 日，发布说明包含消息投递、重连、卡住的发送和模型设置修复。只有本地错误与这些签名吻合时，版本比较才有意义；“升级到最新版”不是所有无回复问题的通用答案。

排障命令的风险不是一个级别

看起来都叫“修复”，实际改变系统的范围差很多。排障时应从低风险往上走，并且每一步都能说明它针对哪个证据。

执行任何写入动作前，先确认活动配置：

hljs bash复制
openclaw config file
openclaw config validate
openclaw doctor --lint --json

Doctor 官方说明明确区分报告与修复。普通 openclaw doctor 用于报告，doctor --lint 是只读诊断；doctor --fix 可以修改配置或状态，强制修复还可能覆盖自定义 supervisor 配置。因此“运行 Doctor 看报告”和“让 Doctor 自动改完”不是同一风险等级。

每次只改一个变量，并记下旧值。改一个 token，就只验证对应认证；改一个端点，就重新 probe 这个端点；修一个 pairing，就从这个渠道发送最短消息。把更新、全量 token 轮换、所有服务重启、会话清理和状态删除放在同一次尝试里，即使突然恢复，也无法知道哪个动作有效，还可能制造第二个故障。

修完以后，必须从原来的入口走完整条链路

进程重新显示 running，不代表用户已经收到回复。验收必须走原来失败的路径。

按以下顺序验证：

1. 重新运行之前失败的同一条 probe；
2. 从原控制台、原私聊、原群或原线程发送一条最短消息；
3. 确认日志在正确时间收到入口事件；
4. 确认预期提供商与模型完成；
5. 确认结果成功投递到原目标；
6. 保留日志一小段时间，确认同一个致命错误不再重复。

日志文档说明了运行日志与控制台输出的来源。核对时要按时间和组件追踪，不要只搜索“error”。启动时的一条旧 warning 不一定影响当前回复；反过来，一次偶然成功之后仍反复出现认证或投递错误，也不能算稳定恢复。

把“立即恢复”和“持续稳定”分开记录。一条成功消息证明链路此刻能通；短时间覆盖同类流量，才能排除自动重连循环、即将过期的凭证、限流或 supervisor 把旧服务重新拉起。

最终记录应能回答四个问题：改了什么、哪个失败信号转为健康、原渠道何时收到成功回复、观察期内是否还有同一错误。这样以后再次出现问题，不需要重新从猜测开始。

需要交给维护者时，准备一份脱敏证据包

如果第一个异常环节已经明确，最小修复却没有奏效，就停止扩大改动。下面这份信息比“我都试过了”更容易复现：

• 一次失败消息的准确时间与时区；
• 哪些入口失败，哪些入口仍正常；
• OpenClaw 版本、所有可执行路径与安装方式；
• 脱敏后的 status --all、Gateway probe/status、渠道 probe；
• 故障前最后一次配置、更新或凭证变化；
• 测试消息前后的一小段相关日志；
• update 状态以及 CLI/服务/配置版本是否一致；
• 已做过的每个动作和结果；
• 只保留字段结构的脱敏配置片段。

不要上传整份环境变量、原始配置、完整聊天历史、会话数据库、token、provider key、Authorization header 或 webhook secret。维护者需要字段名和错误上下文，不需要秘密值。

如果最早失败的是 CLI 找不到、二进制路径混乱或安装归属不清，转到中文 OpenClaw 安装部署指南。这类问题与“CLI 和 Gateway 正常、只有下游渠道不回”不是同一个任务。

常见问题

OpenClaw 显示 running，为什么还是不回复？

running 只说明某个进程存在。连接探测、控制台认证、渠道入口、配对/白名单、模型执行和回传仍可能失败。以第一个无法证明健康的检查点为准。

最安全的第一组命令是什么？

先运行 openclaw status、openclaw status --all、openclaw gateway probe，并在另一个窗口打开 openclaw logs --follow。这组动作先收集证据，不主动执行写入修复。

能不能一开始就运行 openclaw doctor --fix？

不建议。普通 Doctor 报告问题，--fix 会修改配置或状态。先保存活动配置、路径和服务归属，确认 Doctor 指出的条件与现场一致，再决定是否让它写入。

Gateway 要不要先重启？

只有明确的 Gateway 变更需要加载，或托管进程已经证明陈旧时才重启。如果 Gateway probe 正常、只有一个渠道沉默，重启范围通常大于故障范围，还会丢失时间证据。

为什么 Telegram、Discord、Slack、飞书或 QQ 只有一个不回复？

优先检查该渠道的账号 probe、机器人是否加入目标、配对、@ 提及、白名单、token、membership、scope、权限和发送回目标的错误。不要先改模型或重装 Gateway。

更新 OpenClaw 后不回复怎么办？

先比较 which -a openclaw、CLI 版本、Gateway 深度状态、更新状态和 config last-touched version。修复能证明的路径或服务归属不一致，不要因为时间上紧挨更新就直接广泛重装。

OpenClaw 当前最新版是什么？

2026 年 7 月 13 日核对时，GitHub 将 v2026.6.11 标为 Latest。版本会继续变化，应打开当前 release 页面，并确认终端和托管服务实际运行的是哪个副本。

可以删除 ~/.openclaw 解决无回复吗？

不要把删除当成第一轮排障。目录中可能包含恢复配置和解释事故所需的状态。先保存证据、定位组件并尝试窄修复；只有后果、备份和恢复方式都明确时，才评估破坏性恢复。

给维护者或支持人员发什么？

发脱敏时间线、影响范围、版本和路径、聚焦的 status/probe 输出、相关日志窗口、最后变化以及每次尝试的结果。不要发送 token、key、认证头、webhook secret 或未过滤的私人对话。