OpenClaw 消息收不到怎么排查：从 Gateway、Channel 到 Webhook 的实战链路

OpenClaw 真正有意思的地方，不是“又多了一个 Agent 聊天入口”。
它更像一个可以落地的 Agent Gateway：一边接模型和 Agent runtime，一边接 Telegram、Discord、Slack、WhatsApp、飞书、QQ Bot 等真实聊天渠道。

这也是为什么我们一直把它归到“实战派”工具里。
实战派不是只会跑 demo，而是能回答这些问题：

• 消息为什么没有进来？
• Bot 为什么在线但不回复？
• 群聊里为什么必须 @ 才有反应？
• DM 为什么提示 pairing 但一直没走下去？
• Gateway 正常，Channel 也 connected，为什么用户还是看不到结果？

这篇只解决一个高频问题：

OpenClaw 接入渠道后，消息收不到或没有回复，应该怎么排查。

官方文档里已经给出排障入口，尤其是 Gateway Troubleshooting、Channel Troubleshooting 和 Docs Directory。这篇会把它整理成一套更适合实际操作的中文链路。

先给结论：别先怀疑模型

很多人看到 Bot 不回复，第一反应是：

• 模型 key 是不是错了？
• prompt 是不是没写好？
• Agent 是不是挂了？

但在 OpenClaw 这种 Gateway + Channel + Agent runtime 的结构里，消息不回复通常要先分层：

1. Gateway 有没有运行
2. Gateway RPC probe 是否正常
3. Channel 是否真的连通
4. sender 是否允许进入
5. 群聊消息是否满足 mention / allowlist 策略
6. 平台权限或 Webhook 是否把事件送进来了
7. 最后才看模型调用和 Agent 运行

最稳的起手式是先跑这一组命令：

openclaw status
openclaw gateway status
openclaw logs --follow
openclaw doctor
openclaw channels status --probe

这组命令对应的不是“随便看看”，而是五个检查点：

检查点	目的
openclaw status	看整体运行状态
openclaw gateway status	看 Gateway runtime 和 RPC probe
openclaw logs --follow	看实时错误、drop、blocked、pairing 信号
openclaw doctor	看配置和服务层面的阻塞问题
openclaw channels status --probe	看每个渠道的连接和探测结果

如果你只记一条原则，就记这个：

先确认消息有没有资格走进 OpenClaw，再讨论 Agent 为什么没有回答。

第一层：Gateway 是不是活着

先跑：

openclaw gateway status

健康状态里，至少要关注这几类信号：

• runtime 是否 running
• RPC probe 是否 ok
• 当前 Gateway URL / port 是否是你以为的那一个
• 是否有端口冲突
• 是否有多个 Gateway 实例同时监听

如果 Gateway 没起来，后面的 Channel、Webhook、Bot 权限都先不用查。

继续跑：

openclaw doctor

doctor 的价值是把很多“看起来像消息问题”的问题提前暴露出来，比如：

• 配置缺失
• auth token 不匹配
• gateway mode 没打开
• bind 地址不安全
• service 配置和 CLI 配置不一致

这一层的典型判断是：

如果 gateway status 都不健康，先修 Gateway。
如果 Gateway 健康，再看 Channel。

这就是 OpenClaw 实战排障和“凭感觉重装”的区别。

第二层：Channel connected 不等于消息会被处理

接着跑：

openclaw channels status --probe

你要看的不是只有 connected，而是：

• transport 是否 connected
• probe 是否 ok
• audit 是否 ok
• capability 是 read-only、write-capable 还是 admin-capable
• 某个账号或 channel 是否有具体错误

OpenClaw 官方的 Channel Troubleshooting 里也把这条命令放在很前面。原因很简单：Channel 层负责连接真实聊天平台，它健康与否决定事件能不能进来、回复能不能出去。

但这里有一个常见误解：

Channel connected，不代表用户消息一定会触发 Agent。

因为连接后面还有策略层。

第三层：DM 不回复，先查 pairing

如果问题发生在私聊，比如：

• 用户给 Bot 发消息没有回复
• /start 后没有继续
• 日志里出现 pairing 相关字样
• 某个新用户发消息后没有触发 Agent

先查 pairing：

openclaw pairing list --channel <channel>

如果你知道具体账号，也可以更细：

openclaw pairing list --channel <channel> --account <accountId>

常见情况是：

现象	更可能的原因
日志里有 pairing request	sender 需要批准
DM 完全不处理	direct policy 禁止或 sender 未允许
只有老用户能用，新用户不行	allowlist 或 pairing 没补

这一步不要急着改模型。
如果 sender 本身没被允许，模型根本没有机会处理消息。

第四层：群聊没反应，重点查 mention 和 allowlist

群聊是 OpenClaw 最容易“看起来坏了”的地方。

常见现象：

• Bot 在群里
• Bot 在线
• 私聊能回复
• 群里发消息没有反应

这时先看日志：

openclaw logs --follow

重点找这些信号：

mention required
drop guild message
allowlist
blocked
not_in_channel
missing_scope
Forbidden
401
403

它们大致对应这几类问题：

日志信号	可能原因	下一步
mention required	群聊要求 @ Bot 才响应	在群里明确 @ Bot，或调整 requireMention
allowlist / blocked	群、频道或 sender 不在允许列表	检查 channels 配置
not_in_channel	Bot 不在目标频道或没有权限	回到平台侧确认 Bot 加入状态
missing_scope	平台授权范围不足	补平台侧权限
401 / 403	token、权限或平台 API 拒绝	检查凭证和授权

配置侧可以先看：

openclaw config get channels

群聊排障的核心不是“为什么 AI 不说话”，而是：

这条消息有没有被 OpenClaw 的群聊策略允许进入 Agent。

第五层：Webhook 没事件，查平台侧和公网入口

有些渠道依赖 Webhook 或平台事件推送。
这种情况下，OpenClaw 本地正常、配置看起来正常，但平台没有把事件送过来，也会表现为“消息收不到”。

这时按这个顺序查：

1. 平台侧 Webhook URL 是否是当前 OpenClaw 暴露的地址
2. URL 是否能被平台访问
3. 平台事件订阅是否包含消息事件
4. Bot 是否有读取消息的权限
5. token / secret 是否和当前配置一致
6. OpenClaw logs 是否出现平台回调请求

你可以在终端里盯日志，然后从平台侧发一条测试消息：

openclaw logs --follow

如果平台发了消息，但日志里完全没有相关请求，优先看：

• Webhook URL
• 网络访问
• 平台事件订阅
• 平台权限

如果日志里有请求，但被拒绝，再看：

• secret
• token
• auth mode
• allowlist / policy

这一步特别适合用 Small-Step Collaboration Skill 带用户操作。因为用户需要在聊天平台控制台、OpenClaw 终端、浏览器页面之间来回确认状态，一次给一页 SOP 反而容易乱。

第六层：如果能收到消息但没有生成回复，再看模型和 Agent

只有当前面几层都基本健康时，才进入模型和 Agent 层。

可以继续查：

openclaw logs --follow
openclaw status

如果你怀疑是模型 provider 的问题，再看模型状态、配置和当前 Agent 使用的模型。不同版本命令可能略有变化，但排查思路是一致的：

1. 模型 provider 是否可用
2. 当前 Agent 是否路由到正确模型
3. key 是否有效
4. 是否出现 rate limit
5. 是否是长上下文、工具调用或本地模型能力导致失败

如果日志里出现 429、provider error、backend crash、tool schema 相关错误，那才进入模型 / backend 方向。

这时不要把前面的 Channel 问题和模型问题混在一起。

一套可复制的排障记录模板

建议每次排障都保留一份记录。不要只在聊天窗口里临时说一句“好了”。

可以直接复制这个模板：

## OpenClaw 消息不回复排障记录

### 基本信息
- 时间：
- OpenClaw 版本：
- 运行方式：本机 / Docker / 服务器 / WSL2
- 渠道：Telegram / Discord / Slack / WhatsApp / 飞书 / 其他
- 现象：DM 不回复 / 群聊不回复 / Webhook 无事件 / 能收不能发

### 命令结果
```bash
openclaw status
openclaw gateway status
openclaw doctor
openclaw channels status --probe

日志关键词

• 是否出现 pairing：
• 是否出现 mention required：
• 是否出现 allowlist / blocked：
• 是否出现 401 / 403：
• 是否出现 provider / model error：

判断

• Gateway 层：
• Channel 层：
• Policy 层：
• 平台权限层：
• 模型层：

最终修复动作

• 修改了什么：
• 重启了什么：
• 是否复测通过：

这个模板的价值，是让下一次排障更快。  
这也是 OpenClaw 这类工具最该沉淀的东西：不是一次性跑通，而是把真实问题变成可复用经验。

## 最小复测流程

修完后，不要只看一条消息“好像回了”。  
建议做最小复测：

1. 私聊发一条短消息
2. 群聊不 @ 发一条
3. 群聊 @ Bot 发一条
4. 从一个新用户或新账号发一条
5. 重启 Gateway 后再发一条

对应记录：

```md
| 场景 | 是否通过 | 备注 |
| --- | --- | --- |
| DM 老用户 |  |  |
| DM 新用户 |  |  |
| 群聊不 @ |  |  |
| 群聊 @ Bot |  |  |
| Gateway 重启后 |  |  |

这能帮你区分：

• 是平台连接问题
• 是 sender 策略问题
• 是群聊 mention 问题
• 是重启后配置没有持久化
• 还是模型层偶发失败

为什么这能体现 OpenClaw 的实战派定位

OpenClaw 的价值不只是“接入很多平台”。
如果只是接平台，那它很容易被理解成一个聊天 Bot 框架。

更实战的理解应该是：

OpenClaw 把渠道、Gateway、Agent、模型、工具、记忆和运维状态放到同一条可排查链路里。

这意味着你可以逐层定位：

• 是平台没有把事件推过来
• 是 Channel 没有连通
• 是策略层拦截了消息
• 是 Gateway 没跑稳
• 是 Agent route 错了
• 是模型 provider 失败

这类能力，才是它从“概念工具”走向“工作流基础设施”的地方。

相关阅读

• OpenClaw 完整入门指南：从安装到跑通第一条消息
• OpenClaw 常见错误与解决方案：从安装失败到生产排障
• 想学 OpenClaw 落地，有哪些偏实战的网站、博客和资源值得长期看？
• Small-Step Collaboration Skill 是什么：让 Codex、OpenClaw、Hermes 一步一步带用户完成任务
• OpenClaw Gateway Troubleshooting
• OpenClaw Channel Troubleshooting