为什么这篇值得先看
很多人第一次启动 OpenClaw 会被几个名字绕晕：openclaw dashboard、Gateway Dashboard、Control UI、WebChat、TUI。官方文档里，openclaw dashboard 是 CLI 命令，用来尽可能安全地打开或打印控制界面地址；Dashboard / Control UI 是 Gateway 提供的浏览器管理界面，默认和 Gateway 跑在同一端口上。
这篇解决的是首次启动后的搜索意图：你不是要深入理解全部架构，而是想知道“页面打开了，我应该先看哪里”“看到 unauthorized / 1008 是不是坏了”“我能不能把这个页面给团队成员用”。
先抓住这 3 个关键点
openclaw dashboard不是普通网页启动器，它会尽量解析当前认证信息，并在 SecretRef 管理令牌时避免把令牌打印到终端、剪贴板历史或浏览器启动参数里。- Control UI 是管理界面，能力覆盖聊天、Talk、渠道、会话、Cron、Skills、节点、配置和 exec 审批。它不是一个可以随便公网暴露的展示页。
- 首次启动时先确认 Gateway 可达、认证通过、设备配对状态清晰，再进入渠道、Skills 或自动化配置。
三个名字怎么分工
| 名称 | 你实际会怎么用 | 首次启动看什么 |
|---|---|---|
openclaw dashboard | CLI 命令，打开或打印控制界面 URL | URL 是否生成、是否不泄露 SecretRef token、是否能打开浏览器 |
| Web Dashboard | Gateway 在浏览器里提供的仪表盘入口 | Gateway URL、认证方式、unauthorized / 1008 提示 |
| Control UI | 浏览器里的管理界面 | 聊天、渠道、会话、配置、设备配对、Cron、Skills、exec 审批 |
如果你只记一条：第一次上手从 openclaw dashboard 进入 Control UI；Control UI 报错时，再回到 doctor、status 和 Gateway 健康检查。
实操步骤
- 先在本机运行
openclaw dashboard。如果你在无头服务器上操作，可以使用openclaw dashboard --no-open让它只打印 URL 和安全提示。 - 打开本地地址。官方文档里本地 Gateway 常见入口是
http://127.0.0.1:18789/或http://localhost:18789/；启用 TLS 时要注意https://和wss://。 - 如果页面提示共享密钥认证，把配置的 Gateway token 或 password 填到 Control UI 设置中。SecretRef 管理的 token 不应该出现在终端日志里。
- 先看 Gateway Access / Overview 类入口，再看渠道、会话、节点、Skills、Cron 和配置。第一次不要急着改配置，先建立“哪里显示状态、哪里发起动作、哪里审批风险操作”的地图。
- 如果出现 unauthorized、1008、需要配对或 scope 不匹配，先记录提示，再回到 doctor / status / devices 或 pairing 教程排查。
配置或命令示例
openclaw dashboard
openclaw dashboard --no-open
openclaw status
openclaw health --verbose首次启动 10 分钟检查表
- URL 是否来自当前 Gateway。不要在多个本地端口、远程隧道和旧书签之间来回切。
- 认证方式是否清楚：token、password、Tailscale 身份、trusted proxy，还是设备 token。
- 控制界面是否要求设备配对。新浏览器、清除站点数据、切换浏览器配置文件都可能触发重新配对。
- 是否有未知设备、未知配对请求或异常 scope 升级请求。不要为了“先进去”批准看不懂的请求。
- 是否有渠道或插件仍在旧状态。还没接 Telegram / WhatsApp 时，界面里不应该出现你无法解释的账号状态。
- 是否有 exec 审批、配置变更或高风险动作入口。团队环境下，这些入口需要 owner 和审批策略配合。
看到 1008 / unauthorized 怎么判断
| 现象 | 常见含义 | 先做什么 |
|---|---|---|
| 页面打不开 | Gateway 未启动、端口不对、隧道不通 | openclaw status、openclaw gateway、确认 18789 端口 |
| unauthorized | 共享密钥、password 或设备 token 不匹配 | 检查 Gateway auth 来源，不要先轮换全部密钥 |
| 1008 需要配对 | 新设备或新浏览器需要批准 | openclaw devices list 后按 requestId 批准 |
| scope mismatch | 设备被识别，但请求了更宽权限 | 明确批准新 scope，或撤销后重新配对 |
| SecretRef token 无法注入 | 当前 shell 解析不到外部 secret | 导出所需环境变量，或按官方 SecretRef 路径修复 |
风险边界
- Control UI 是管理界面，不是公开站点。它涉及聊天、配置、节点、Cron、Skills 和 exec 审批，公网暴露会把管理面变成攻击面。
gateway.controlUi.allowedOrigins: ["*"]这类宽松来源策略不适合真实环境。除非是严格受控的本地测试，否则应按官方文档显式配置来源。- URL 片段里的 token 只适合引导当前会话；不要把带 token 的 URL 发给别人或贴进文档。
- 如果你正在调远程 Gateway，优先使用 Tailscale Serve、SSH 隧道或受控反向代理，不要直接把 loopback 以外的未受保护端口暴露出去。
常见坑
- 把所有问题都归因到 Control UI，结果忽略了 Gateway 根本没起起来。
- 把
openclaw dashboard --no-open打印的 URL 和旧书签混用，最后连到了另一个环境。 - 看到 unauthorized 就轮换 token，结果真正问题是 scope mismatch 或设备配对没批准。
- 第一次启动就接入多个渠道，界面信息过多，反而不知道哪个报错是主因。
- 只盯着聊天窗口，不看 Gateway Access、devices、channels、sessions 和 exec approvals。
完成检查
- 你能说清楚
openclaw dashboard、Web Dashboard 和 Control UI 各自解决什么问题。 - Control UI 可以打开，认证方式清楚，没有残留的未知授权、未知配对或异常 scope 请求。
- 你知道在哪里看 Gateway 访问状态、在哪里看渠道/会话、在哪里处理审批或配置变更。
- 界面异常时，你知道该先看 OpenClaw 排错清单，而不是盲目重装。
下一步怎么选
- 界面打不开或认证失败：继续读 OpenClaw 排错清单。
- 页面能打开，想理解审批和高风险动作：继续读 OpenClaw 审批流实战。
- 准备连接新设备或消息渠道：继续读 OpenClaw pairing 教程。
为什么建议把这篇收藏起来
- 这篇能帮你减少“看得到界面，但不知道该点哪里”的空转时间。
- 以后接入更多 channels、Skills、Cron 或团队审批时，仍然会回到这个界面分工和安全边界。