OpenClaw 日志诊断教程 logs status 和网关排障指南

Gateway 排障时，最常见的错误路径是“先猜配置哪里错了”。但官方帮助文档给出的顺序其实很明确：先看日志和状态，再决定后续动作。因为在 OpenClaw 里，很多表面上看像模型、渠道或控制台的问题，最后根因其实只是 Gateway 本身没稳定跑起来。

最值得先跑的命令#

先记住这三条：

openclaw logs --follow
openclaw gateway status
openclaw status --deep

它们是日常诊断最有价值的一组组合。

这三条命令分别在看什么#

openclaw logs --follow

负责看：

• 实时错误
• 启动信息
• 渠道、模型和工具相关运行日志

这是你最接近“系统正在发生什么”的入口。

openclaw gateway status

负责看：

• Gateway 服务是否真的在运行
• 它是不是已经被服务管理器正确接管
• 当前问题是不是因为中心服务根本没起来

openclaw status --deep

负责看：

• 更深层的系统健康状态
• 渠道探测情况
• 模型探测情况

它更像全系统体检，而不只是看 Gateway 进程本身。

为什么这个顺序很重要#

因为很多问题表面上看起来像：

• 模型坏了
• 渠道不工作
• Dashboard 打不开

但如果你先看日志和服务状态，常常会发现真正根因只是：

• Gateway 没有启动
• 服务没有被正确接管
• 启动后立刻报错退出

这种情况下，你如果先去改 provider 配置、改群组规则、改远程访问，只会把问题越搅越乱。

官方还提到哪些状态命令#

除了上面三条，官方 status 文档里还常提到：

openclaw status
openclaw status --all
openclaw status --usage

它们大致可以这样理解：

• status：总览
• status --all：更完整的诊断输出
• status --usage：provider 用量或使用快照

在你已经知道大致问题方向后，这几条可以继续补充信息。

一个推荐排障顺序#

如果今天真的遇到故障，我建议先按这个顺序走：

1. openclaw gateway status
2. openclaw logs --follow
3. openclaw status --deep
4. 再决定问题是在模型、渠道还是控制台层

这套顺序的价值在于，它会先把“服务层死没死”这件事回答清楚。

日志为什么比猜配置更值钱#

因为日志提供的是直接证据，而猜配置通常只是想象。特别是在这些场景里：

• 渠道不回消息
• Dashboard 打不开
• 模型似乎不工作
• 启动后行为异常

日志几乎总能比“我觉得可能是 XXX”更早给出方向。

一个实用原则#

以后只要你遇到 OpenClaw 异常，先不要急着改配置文件。先确认两件事：

• 服务是不是活着
• 日志里到底在报什么

这两件事一旦清楚，后面的排障成本会低很多。