ARTICLE · 1001459
OpenClaw 接入飞书不回消息,问题到底出在哪?
OpenClaw 接入飞书不回消息,问题到底出在哪?
一条消息在服务器之间穿行，最怕在看不见的地方悄悄断掉。 你给飞书里一个 AI 机器人发消息。消息发出去了，日志显示机器人也在"思考"，模型也正常返回了答案——可你就是等不到回复。更迷惑的是，同一台电脑上，另外几个机器人却好好的。 这不是玄学。这是一条消息从"发出去"到"回过来"之间，某个环节悄悄断掉的典型表现。 这篇文章记录一次真实的排障：一个接入飞书的开源 AI 网关（OpenClaw），从"收到消息却不回复"到彻底修好的全过程。你会看到三个隐藏的坑，以及一套以后能复用的排查方法。 一条飞书消息走完，要经过五个环节：用户发消息，飞书开放平台把事件推给机器人，接入网关收到，网关把消息派给对应的大模型，模型生成回复，网关再把回复发回飞书。 任何一个环节断掉，表现都一样：机器人"没回复"。所以排障的第一原则不是猜，而是先确认——消息到底走到哪一步了。 
一条消息的完整旅程：用户、平台、网关、模型、回复，环环相扣。 简单说，飞书里的"AI 机器人"是一个常驻后台的程序，负责三件事：接消息、想答案、发回复。 但它不等于模型本身，也不是一个孤立的程序，而是"多个机器人 + 一个中央网关"的组合。飞书只是入口，真正干活的是网关和模型。任何一边出问题，机器人在用户眼里都只是"死了"。 这次排障一共挖出三个问题：前两个解释"为什么只收不回"，第三个解释"为什么过几天又全哑了"。 【第一个坑】一个"卡死"的会话，把消息拦在了门口。 最初的现象：消息能收到，但日志反复出现 Session changed while starting work. Retry，派发到一半就被拒，消息根本没走到模型。 原因是这个版本的已知问题——网关重启后，恢复的"活动归属"会一直保留，导致同一会话后续的消息全部被判为"归属冲突"而拒绝派发（对应上游仓库的已知问题#116694、#111862）。 修复方式很直接：定位到这个卡死的会话并删掉。删除的瞬间，消息立刻能进模型、正常回复。 启发：当"其他都正常、就这一个会话死"时，优先怀疑会话状态，而不是网络。 【第二个坑，真正的元凶】一个看不见的"隧道"，把流量劫持走了。 会话修好后，回复还是时好时坏。日志里两种报错交替出现：流式卡片更新 Update failed: TypeError: fetch failed，以及最终回复 connect ETIMEDOUT 198.18.0.220:443——一个非常可疑的 IP。 查下去发现：系统里有一个 TUN 隧道网卡（sing-tun / Wintun），它把 open.feishu.cn 的 DNS 解析"劫持"成了 198.18.0.220 这个假 IP。所有发往飞书的流量都先钻进这个隧道，而隧道对这条链路转发极不稳定：新建的连接能通，长驻连接却间歇性超时。 这也解释了一个最迷惑的现象：为什么其他机器人正常？因为隧道是"抽风"式的。其他机器人测试时恰好撞上好的时候；主机器人消息密集，每次都踩到坏连接，问题就最明显。ETIMEDOUT 到假 IP，就是铁证。 修复方向：给飞书和模型域名加"直连"规则绕过隧道，或者干脆关掉这个隧道。 启发：当一个工具"一会儿通、一会儿不通"，且报的是 TCP 连接超时、目标还是可疑 IP 时，先查本机的 TUN / VPN 隧道，别急着怀疑代码。 【第三个坑】网关"半夜猝死"，却没人把它拉起来。 某天凌晨，网关进程悄然消失，端口无人监听，第二天所有机器人一起哑火。日志最后一条还是正常成功的调用——说明它根本不是崩溃，而是被系统（睡眠 / 现代待机）悄悄挂起带走了。 原因：网关只靠"登录时启动"的方式拉起，进程一旦消失，没有任何机制自动拉回。 修复：启用一个每 2 分钟探活、发现网关挂了就自动重启的"看门狗"定时任务。 启发：常驻服务只有"开机自启"是不够的，必须配套"死了能自动拉回来"的自愈机制。 很多人一听到"只有某个机器人不正常"，就自动排除网络问题。这个判断要打一个问号。 关键要看错误的类型：如果是明确的业务错误（权限、参数、回调地址），那确实是配置问题；如果是 ETIMEDOUT、fetch failed 这类网络层错误，哪怕只是偶发，也要认真对待——它说明网络链路本身不稳定，只是还没到"每次都挂"的程度。 单看"其他正常"会误导方向；结合报错类型看，才能锁定真凶。 【误区一】模型没回复，一定是模型的问题。不一定，消息可能根本没派到模型（被会话状态拦下）。 【误区二】命令行能连通，说明网络没问题。curl 用的是新建连接，而工具的长驻连接才是问题所在；要看的，是工具自身的日志报错。 【误区三】重启一下就好。如果根因是会话状态或隧道，重启只是暂时掩盖，问题很快会回来。 第一步，看日志，确认消息走到哪一环：收到？派发？进模型？回复？先定位到具体环节。 第二步，看错误类型：业务错，查会话、权限、配置；网络错（ETIMEDOUT / fetch failed），查 TUN / VPN 隧道、代理、DNS 劫持。 第三步，看是不是单会话异常：只有某个会话死，优先清会话状态；全部异常，查网关和网络。 第四步，给常驻服务配自愈：看门狗 + 日志监控，别只靠"开机自启"。 排障的本质，是把"看起来像玄学"的问题，拆成可以逐步验证的环节。 这次最大的收获是：真正卡住回复的，往往不是最显眼的地方。模型没问题是假象，一个藏在系统里的网络隧道，才是那个"看不见的元凶"。 边界提醒：不同版本、不同平台的细节可能不同，报错、路径、命令都应以你实际环境的日志为准。这是一份经验记录，不是万能答案。 
写给每一个正在和"只看得到输入、看不到输出"斗智斗勇的人。 本文所有故障现象、日志报错、修复动作，均来自作者本人 2026 年 8 月底在 Windows 上的真实排障记录（OpenClaw 2026.9.1-beta.1）。 涉及的已知问题编号（#116694、#111862）为排障时检索到的上游仓库 issue，具体修复状态以官方仓库当前为准。 三张配图（头图、链路示意图、封面图）均为 AI 生成的示意图，非真实截图或现场照片。 文中版本号、IP、命令均为排障当时的实测值，不同环境可能存在差异。
写在前面：一次真实的排障
一、真正要解释的，不是"为什么坏"，而是"卡在哪一环"
二、先把"机器人"说清楚：它不是一个人，而是一条流水线
三、三个"真凶"，一个比一个隐蔽
四、一个关键反转：为什么"其他机器人正常"不矛盾
五、几个常见误区，先排除
六、以后遇到"机器人只收不回"，按这套框架排查
写在最后
封面图
备选标题