OpenClaw logs 怎么看：openclaw logs --follow 与排障顺序一次讲清

发布时间

2026-03-14

作者

BUMA 内容团队

资料来源

OpenClaw 官方 Troubleshooting / Gateway troubleshooting、Clawdbot 中文文档

适合谁看

正在排查 OpenClaw 无回复、Dashboard 连接异常、飞书消息不流动、cron 没投递的人

OpenClaw 官方建议的排障顺序，为什么比直接盯日志更稳？

因为日志本身只会告诉你“刚刚发生了什么”，却不一定自动告诉你“这是哪一层的问题”。OpenClaw 官方 Troubleshooting 页面把前 60 秒的顺序写得很明确：先看 openclaw status，确认基本配置和明显认证错误；再看 openclaw status --all，拿完整报告；接着用 openclaw gateway probe 验证目标网关是否可达；然后用 openclaw gateway status 看运行态是否是 Runtime: running、RPC 是否正常；再跑 openclaw doctor 排掉配置或服务级阻塞；再用 openclaw channels status --probe 看渠道是否 connected 或 ready；最后再开 openclaw logs --follow 对照实时行为。

这套顺序的好处在于，你不会因为看到一条局部日志就误判全局。例如有些人看到群里机器人不回，第一反应是“Gateway 挂了”；但如果前面的 gateway status 和 channels status --probe 都是健康的，那么更可能是 mention 策略、pairing 审批、群白名单或发送者白名单问题。也就是说，日志必须结合前面的状态命令一起看，才不会把路由问题、权限问题和服务问题混成一团。

中文文档的表达也基本一致：无论是飞书接入页还是故障排除页，都把 openclaw gateway status 与 openclaw logs --follow 放在同一条检查链上，而不是把日志单拎出来。这一点很重要，因为很多用户实际搜“OpenClaw logs 怎么看”，背后真正想解决的是“我下一步该先查哪层”。

真正实用的“前 60 秒检查链”应该怎么记？

第一步：openclaw status。它更像总览页，用来先看当前渠道、模型、认证有没有明显不对。

第二步：openclaw status --all。官方把它定义成更完整、可分享的报告，适合在协作排障时快速对齐事实。

第三步：openclaw gateway probe。这一步是为了确认你当前指向的网关目标是否可达，避免你后面所有排查都建立在“连的其实不是这个网关”之上。

第四步：openclaw gateway status。重点看 Runtime: running、RPC probe: ok，以及 Dashboard URL、服务状态、监听信息。

第五步：openclaw doctor。它不是可有可无的小检查，而是帮你先把配置层和服务层的阻塞找出来，省得你对着业务日志瞎猜。

第六步：openclaw channels status --probe。如果你走的是飞书、Telegram、Discord 这类消息渠道，这一步能快速判断 transport 是不是真的连上了。

第七步：openclaw logs --follow。放到最后，才真正有意义。此时你看到的每条日志，都能放回正确语境里解释，而不是越看越乱。

不同场景下，日志应该和哪些命令一起看？

如果你遇到的是 没回复，官方建议把 pairing list、channels status --probe 和 config get channels 一起看，因为这里大概率是路由或策略问题。要是你遇到的是 Dashboard / Control UI 连不上，重点则会转到 gateway status、doctor 和认证细节码，比如 AUTH_TOKEN_MISSING、AUTH_TOKEN_MISMATCH、PAIRING_REQUIRED。如果你遇到的是 网关服务起不来，日志又要配合 gateway status --deep、端口监听和服务配置去看，常见是 gateway.mode 没配对、非 loopback 绑定没带认证，或者端口冲突。

如果你遇到的是 cron 没跑 或 heartbeat 没投递，官方 runbook 也不是让你只盯日志，而是先看 openclaw cron status、openclaw cron list、openclaw cron runs，确认调度器是否开启、最近运行结果是 ok、skipped 还是 error，然后再回日志里找 scheduler disabled、timer tick failed、quiet-hours、requests-in-flight 这类关键词。这样才能分清是调度器没动、投递目标不对，还是主通道太忙导致被延后。

为什么很多人会把“OpenClaw logs 看不懂”误判成产品不稳定？

一个很常见的原因是：用户把所有问题都压到日志层去理解，而没有先做层级拆分。日志里既会出现网关运行态，也会出现渠道状态，还会出现权限拒绝、配对审批、群聊 mention、Cron 投递等不同来源的信号。如果你没有先分清“我现在排查的是服务层、连接层、渠道层，还是策略层”，日志自然会显得杂乱。

另一个原因是，很多人期待日志能直接给一个“唯一答案”。但 OpenClaw 官方文档的写法已经说明了：日志更适合用来验证判断，而不是代替判断。比如你看到 drop guild message (mention required) 或 mention required，正确动作是回去看群配置；看到 pairing request，正确动作是看审批列表；看到 AUTH_TOKEN_MISMATCH，正确动作是看认证与设备 token；看到 EADDRINUSE，正确动作是处理端口冲突。也就是说，日志的价值在于“帮你选下一步动作”，而不是“自己就把问题修完”。

对中文用户来说，这篇最重要的价值，不是把每条日志逐行翻译，而是帮你建立一个更稳定的排障顺序：先状态、再健康、再渠道、最后日志。顺序一旦对了，日志就不再像噪音，而会变成非常高效的线索。