OpenClaw Dashboard 打不开怎么办：gateway status、unauthorized 与 1008 排查一次讲清

发布时间

2026-03-14

作者

BUMA 内容组

资料来源

OpenClaw 官方 Getting Started、Dashboard、Gateway Troubleshooting、FAQ 与 Clawdbot 中文文档。

适合谁看

已经装好 OpenClaw，但在打开 Dashboard、连接 Control UI 或验证 Gateway 状态时卡住的人。

OpenClaw Dashboard 到底是什么

官方 Dashboard 文档把它定义得很直接：Gateway Dashboard，也就是浏览器里的 Control UI，默认由 Gateway 的根路径 / 提供。它不是一个和 Gateway 平行的单独程序，而是 Gateway 暴露出来的管理界面。所以你看到 Dashboard 无法使用时，第一反应不应该是“网页前端坏了”，而应该先回头看 Gateway 本身是否真的运行、能否被当前浏览器访问、认证方式是否一致。

这个界面之所以重要，是因为它不只是聊天窗口。官方文档明确把它归类为 admin surface，也就是管理面，里面涉及聊天、配置、执行审批等能力。也正因为如此，官方特别提醒不要把 Dashboard 直接暴露到公网。对一人公司和小团队来说，最稳的路径还是本地 localhost、Tailscale Serve，或者临时 SSH 隧道，而不是图省事把端口直接敞开。

换句话说，如果你只是想快速判断 OpenClaw 是否已经可用，最短路径不是折腾一堆复杂配置，而是回到 Getting Started：先让服务跑起来，再用 openclaw dashboard 打开控制台，或者直接访问 http://127.0.0.1:18789/。官方中文社区文档也给出了同样顺序，这说明这一步不是“社区经验”，而是产品默认设计。

最省时间的排查顺序：先跑命令，再看浏览器

第一步：看总状态

官方 Troubleshooting 给出的 command ladder 第一条就是 openclaw status，目的是先确认当前 OpenClaw 总体有没有起来、CLI 与 Gateway 是否对得上。

第二步：看 Gateway 健康度

紧接着是 openclaw gateway status。如果这里看不到 Runtime: running 和 RPC probe: ok，不要急着开浏览器，因为浏览器层只是表象，根因还在服务层。

第三步：看日志与 doctor

官方 runbook 把 openclaw logs --follow 和 openclaw doctor 都放进了默认排查链路，原因很简单：端口冲突、服务配置错位、token 配置问题、设备授权异常，这些都更容易在日志和 doctor 里直接暴露。

第四步：最后再回浏览器

等服务与认证前提确认无误后，再用 openclaw dashboard 或手动打开默认地址去验证。这个顺序能避免很多“其实是后端没起来，却一直在前端反复刷新”的无效动作。

本地访问和远程访问，别混成一个问题

官方 Dashboard 文档把本地与远程的路径分得很清楚。对于本地 Gateway，默认就是在本机打开 http://127.0.0.1:18789/，这是最简单、变量最少的路径。只要 openclaw gateway status 正常，这个地址通常就该能打开。

远程场景则完全不同。官方建议优先使用 Tailscale Serve，或者 SSH 隧道，例如把远端 127.0.0.1:18789 映射回本机再访问。原因不是“官方更保守”，而是 Dashboard 本质上是管理面，直接暴露在公网风险很高。你如果在远程环境看到 unauthorized、device identity required、连接不上，先问自己一个问题：现在这次访问，到底算本地直连、Tailscale、还是 SSH 隧道？这三种路径的认证与安全前提不一样，混在一起排查只会越查越乱。

中文社区文档也强调了同样一点：如果 token 由 SecretRef 管理，openclaw dashboard 可能故意只给你一个不带 token 的干净链接，这不是少给了信息，而是避免把敏感 token 暴露在 shell 日志、剪贴板历史或浏览器启动参数里。遇到这种情况，正确动作是去 Dashboard 设置里手动粘 token，而不是怀疑命令失效。

一套够用的实战判断：先看这 5 个点

第一，看 Gateway 是否真的运行。 没有 Runtime: running，其他都不用往下谈。

第二，看 RPC probe 是否正常。 官方把 RPC probe: ok 作为健康信号之一，说明 CLI 与 Gateway 的本地探测链路是通的。

第三，看你访问的是本地还是远程。 如果是本地，就先别跳去公网地址；如果是远程，就别继续把 localhost 心智套进去。

第四，看 token 来自哪里。 是明文配置、环境变量、还是 SecretRef 管理？来源不清，最容易出现 token mismatch。

第五，看是否存在设备授权。 如果错误详情已经明确指向 PAIRING_REQUIRED 或设备 token 漂移，继续刷新网页意义不大，应该转去设备批准链路处理。

只要把这 5 个点按顺序过一遍，大多数 OpenClaw dashboard 打不开、OpenClaw gateway status 看不明白、OpenClaw unauthorized / 1008 反复出现的问题，都能在较短时间内被定位到具体层级，而不是停留在“好像哪都不对”的模糊状态。