群里最近又开始刷屏了：

"飞书机器人怎么突然不回消息了？"

"昨天还好好的，今天就没反应了？"

说实话我自己也被坑过好几次。有一次 Mac 系统更新完重启，我还在那研究是不是飞书后台出了什么幺蛾子，折腾了半小时才发现——Gateway 根本没跑起来。

当时真的想扇自己一巴掌。

今天把我踩过的坑和排查经验整理了一下，下次飞书断了，照着查就行，不用瞎猜。

先搞清楚一件事

很多人以为飞书连接走的是 Webhook，飞书那边推消息过来。

其实不是。

OpenClaw 用的是 WebSocket 长连接。简单说就是 OpenClaw 自己主动去连飞书，不需要你有公网 IP，不需要配域名，什么都不用。

但这就带来一个问题：

Gateway 进程一挂，连接直接断。

所以飞书突然不回消息，第一反应别去飞书后台翻来翻去，先看看自己的 Gateway 还活着没。很多人在这一步就已经走偏了。

30 秒定位问题

别想太多，终端里跑这四条：

openclaw gateway statusopenclaw channels status --probeopenclaw logs --followopenclaw doctor

然后对照这个表看：

跑完这四条，90% 的情况都能定位到具体原因。真的，不用想太复杂。

Gateway 没在跑（最最最常见）

这个是第一名，没有之一。

电脑重启了、系统更新了、手动关了终端、进程崩了——不管什么原因，Gateway 一挂就完蛋。

之前我那次就是这样，Mac 更新重启完，openclaw gateway status 一看：Runtime: stopped。

好嘛，啥都不用查了。

openclaw gateway start

搞定。

如果 start 没反应——偶尔会遇到 Daemon 元数据损坏的情况——那就强制来：

openclaw gateway install --force && openclaw gateway start

然后确认一下：

openclaw gateway status --deep# 看到 Runtime: running，RPC probe: ok 就对了

怎么防止这事再发生？配个开机自启就完了：

# macOSlaunchctl list | grep openclaw# Linuxsystemctl enable openclaw

这步不做的话，每次电脑重启你都得手动开一次 Gateway，迟早忘。

飞书 App Secret 失效了

这个坑比较隐蔽，因为之前一直好好的嘛。

但有时候飞书管理员会重置应用密钥（可能他自己都不知道改了什么），有时候是 .env 文件没加载上。

先确认当前配置对不对：

openclaw config get channels.feishu

如果有问题，重新配。推荐环境变量的方式，改一个文件就行：

# ~/.openclaw/.envFEISHU_APP_ID=cli_xxxxxxxxxxxxxxFEISHU_APP_SECRET=你的应用密钥

凭据去哪拿？飞书开放平台（open.feishu.cn）→ 我的应用 → 凭证与基础信息。App ID 和 App Secret 都在那个页面。

改完不用重启 Gateway！直接执行：

openclaw channels loginopenclaw channels status --probe

热重载，立刻生效。

权限没开够

有些人连接是连上了，但消息收不到、也发不出去。日志里一堆 missing_scope 或者 Forbidden。

去飞书开放平台 → 应用权限，搜索添加这几个：

这里有个大坑：企业版飞书的权限改完要管理员去后台审批！

不审批就不生效。我之前帮人调试的时候在这卡了好久，后来才想起来问他"你们管理员审批了没"，果然没有。

审批通过之后跑一下：

openclaw channels login

事件订阅没配对

这个问题最坑人。因为 Gateway 状态显示正常，渠道也连着，但就是不响应。

WebSocket 长连接模式下，飞书那边需要你手动开启几样东西。少了任何一个都不行：

1、飞书开放平台 → 应用功能 → 机器人 → 确认启用了

2、事件订阅 → 接收方式切成"使用长连接接收事件"

注意别选成 Webhook URL 模式！很多人在这选错了。

3、添加事件：搜索 im.message.receive_v1

配好之后验证：

openclaw logs --follow | grep -i "feishu\|lark"

能看到连接建立的日志就 OK。

消息被路由策略吃掉了

最后一种情况。Gateway 正常、渠道也通，但发消息就是石沉大海。

先看日志：

openclaw logs | grep "drop"

常见的几种 drop 原因：

mention required → 群里没 @Bot。默认配置下群消息必须 @机器人才会处理，直接发消息它是不理你的。

pairing pending → 私聊用户没配对。跑 openclaw pairing list feishu 看看有没有待批准的。

not in allowlist → 不在白名单。要么加白名单，要么改 open 策略。

channel disabled → 渠道被禁了。配置里改成 enabled: true。

如果你想一步到位，把私聊和群组都开放（安全性自己评估哈）：

{  "channels": {    "feishu": {      "enabled":true,      "appId": "${FEISHU_APP_ID}",      "appSecret": "${FEISHU_APP_SECRET}",      "dmPolicy": "open",      "groupPolicy": "open",      "groups": {        "*": { "requireMention":true }      }    }  }}

断了会自动重连吗？

会。WebSocket 断了之后 OpenClaw 会自动重试，指数退避，最多 3 次，最长间隔 30 秒。

网络抖一下之类的小问题，基本能自动恢复，不用管。

但如果持续连不上，那就要手动介入了：

openclaw channels login

配个心跳，防患于未然

OpenClaw 自带心跳机制，默认 30 分钟探一次。觉得太慢可以调短：

{  "agents": {    "defaults": {      "heartbeat": {        "every": "10m",        "target": "last",        "directPolicy": "allow"      }    }  }}

心跳如果只返回 HEARTBEAT_OK，不会推送给用户，完全静默。

几个群里经常问的

"飞书后台显示连接正常，但 OpenClaw 这边没反应？"

飞书那边状态有延迟，以 OpenClaw 日志为准。日志里一直 reconnecting 循环的话，大概率是 App Secret 错了或者权限没审批。

"换了个飞书应用，旧的还连着怎么办？"

openclaw config unset channels.feishuopenclaw channels login

先清后配。

"群里正常但私聊不回？"

私聊走 dmPolicy，默认 pairing 模式，要先配对才行。跑 openclaw pairing list feishu 看看有没有待批准的请求，嫌麻烦就直接改 open。

"企业版飞书有啥区别？"

权限审批更严格，应用要管理员在后台批准安装。用企业飞书的话，先确认应用被管理员批准了，再来配 OpenClaw，不然白折腾。

写在后面的话

飞书连接断开说白了就四步排查：Gateway 活没活 → probe 通不通 → 日志报啥 → 对症下药。

95% 的情况都跑不出这四步。

关注我，加群，分享更多的 AI 知识。