写在前面
平台接入失败时，最常见的误区不是不会改，而是一上来就乱改。
正确做法是先把问题归类，再决定下一步改哪里。你现在不要同时改平台后台、OpenClaw 配置和权限策略，而是先按顺序看状态、日志和测试入口。
第一步：先确认失败表现属于哪一种
先把现象说清楚。最常见的失败表现有四种：
- 渠道根本连不上；
- 渠道显示已连接，但消息发出去完全没反应；
- 消息已经进入系统，但没有正常回复；
- 私聊正常，群组或频道异常。
这一步很重要，因为不同表现对应的排查入口完全不同。
第二步：先看渠道状态，不要只看平台表面现象
执行：
openclaw channels status
openclaw channels status --probe判断方式：
- 如果这里已经报认证失败、配置缺失或连接错误，优先查凭据和渠道配置；
- 如果这里正常，但平台还是没有反应，再继续看日志；
- 如果这里状态本身就不稳定，不要继续只盯平台侧。
只看到 connected 不代表链路已经可用。它只能说明某一层连接建立了，不能说明消息已经闭环。
第三步：再看日志，判断消息到底卡在哪一层
执行：
openclaw logs --follow如果需要，也可以补看最近日志：
openclaw logs --limit 100你现在主要判断三件事：
- 测试消息有没有进入日志；
- 日志里有没有持续性的认证、权限或 pairing 错误；
- 主进程本身是否稳定运行。
如果你发了测试消息，日志里完全没有任何相关记录，问题更像平台侧没有把事件送进来。
如果日志里已经有消息进入，但后续处理失败，问题更像 OpenClaw 侧配置、权限或运行状态。
第四步：按下面五类继续分诊
1. 凭据没有真正生效
常见表现：
--probe直接报认证失败；- 平台侧明确拒绝连接；
- 改过 Token 但状态一直没变化。
先检查：
- Token 是否填错；
- 环境变量是否真的生效；
- 修改后是否已经重新加载或重启。
2. pairing 没批准
常见表现：
- 渠道看起来已接通；
- 日志里能看到消息，但系统不继续响应；
- 问题最像“已经连上，但就是不回复”。
这类问题不要再去猜平台权限，先确认 pairing 或审批链路有没有通过。
3. 提及、白名单或群组门控导致消息没被接收
常见表现：
- 私聊正常，群组异常；
- 某些频道正常，另一些频道完全无响应；
- 只有在特定提及方式下才会触发。
这时先停在入口规则层排查，不要误判成主进程故障。
4. 平台侧权限不足
这类问题在 Discord、飞书更常见。
常见表现：
- 渠道存在，但某些消息类型收不到；
- Bot 在线，但频道里无响应；
- 平台后台权限或事件订阅明显不完整。
优先回对应平台页，逐项检查平台侧设置。
5. 主进程或配置本身不稳定
常见表现：
openclaw status或日志本身就异常；- 渠道之外还有其他运行问题；
- 修改配置后行为和预期完全不一致。
这时不要继续只看平台接入，应该先回到整体配置或故障排查层。
一个够用的最小分诊顺序
大多数情况下，按这个顺序查就够了：
openclaw channels status
openclaw channels status --probe
openclaw logs --follow然后问自己三个问题：
- 渠道状态是否正常；
- 测试消息是否进入日志；
- 错误更像平台侧、渠道配置，还是主进程。
只要这三个问题答清楚，下一步一般就不会走偏。
常见错误或风险
- 看到
connected就停止排查； - 还没分清是私聊问题还是群组问题，就一起改；
- 平台侧和 OpenClaw 侧同时大改，最后没有因果线索；
- 日志还没看，就直接重建渠道或重装；
- 明明是平台权限问题，却一直在猜模型或技能问题。
下一步
如果你已经判断是平台特定问题，回对应平台页继续处理，比如 Telegram 接入、Discord 接入 或 飞书接入。
如果问题更像配置没有真正生效，继续看 配置没有生效先查什么。
如果问题已经扩大到整体运行状态，继续看 故障排查总页。