【OpenClaw】启动报错 disconnected (1008): unauthorized: gateway token mismatch

【OpenClaw】启动报错 disconnected (1008): unauthorized: gateway token mismatch


📑 文章目录

  1. 一、问题现象
  2. 二、错误原因分析
  3. 三、快速修复(60 秒)
  4. 四、Docker 用户特别注意
  5. 五、彻底修复(停止 → 清除 → 重启)
  6. 六、易混淆错误辨析
  7. 七、常用命令速查表
  8. 八、总结

一、问题现象

OpenClaw 启动后,控制台输出以下报错信息:

disconnected (1008): unauthorized: gateway token mismatch (open the dashboard URL and paste the token in Control UI settings) 

该错误属于 WebSocket 握手阶段的认证失败,错误码 1008 是 WebSocket 协议中定义的 “Policy Violation”,表示服务端因策略原因主动拒绝连接。


二、错误原因分析

当客户端(CLI、远程节点或 Control UI 浏览器)连接到 Gateway 时,会在握手阶段携带一个 Token。Gateway 会将该 Token 与自身配置中的 gateway.auth.token 进行比对。一旦不匹配,Gateway 将立即拒绝 WebSocket 连接,返回 1008 错误。

常见导致 Token 不匹配的场景:

  • 🔄 Gateway 重启后生成了新的 Token,但客户端仍使用旧 Token
  • 🌐 通过浏览器收藏夹/旧标签页访问 Dashboard(URL 中不含最新 Token)
  • 📝 手动修改了配置文件中的 auth.token,但未同步更新 remote.token
  • 🐳 Docker 环境变量静默覆盖了挂载配置文件中的 Token 值

三、快速修复(60 秒)

方法一:重新打开带 Token 的 Dashboard URL

如果你是通过浏览器的旧标签页或直接访问 http://127.0.0.1:18789/ 打开的 Dashboard,那么浏览器不会携带当前有效的 Token。

修复步骤:

# 方式 1:自动打开浏览器 openclaw dashboard # 方式 2:仅输出 URL,手动复制到浏览器 openclaw dashboard --no-open 
⚠️ 安全提示

请勿收藏带 Token 的 Dashboard URL!Token 应当被视为密码,每次通过命令获取即可。

方法二:对齐配置文件中的 Token

打开配置文件 ~/.openclaw/openclaw.json,重点关注以下两个字段:

{"gateway":{"auth":{"token":"my-secret-token"// ← Gateway 服务端使用},"remote":{"url":"ws://localhost:18789","token":"my-secret-token"// ← 客户端使用(必须与上面一致!)}}}

确认 auth.tokenremote.token 的值完全一致。如果不同,使用以下命令同步:

# 将 remote.token 设置为与 auth.token 一致 openclaw config set gateway.remote.token "YOUR_AUTH_TOKEN_HERE"# 重启 Gateway 使配置生效 openclaw gateway restart 

方法三:使用自动诊断修复

OpenClaw 内置了诊断工具,可以自动检测并修复大多数配置问题(包括 401 Unauthorized、429 Rate Limit Exceeded、Token Mismatch 等):

openclaw doctor --fix
推荐

如果你不确定问题根因,优先尝试 openclaw doctor --fix,它能覆盖大部分常见配置错误。

四、Docker 用户特别注意

在 Docker 中运行 OpenClaw 时,docker-compose.ymldocker run 命令中设置的 环境变量会静默覆盖挂载配置文件中的值。这意味着:即使 ~/.openclaw/openclaw.json 中的 Token 是正确的,一个过时的 OPENCLAW_GATEWAY_TOKEN 环境变量也会导致持续报错,且常规排查无效。

🔍 排查方法

# 进入容器查看所有 OpenClaw 相关环境变量dockerexec<container_name>env|grep OPENCLAW 

如果输出中出现 OPENCLAW_GATEWAY_TOKEN,且其值与配置文件中的 gateway.auth.token 不一致 —— 这就是问题所在

🛠️ 修复方法

docker-compose.yml 中更新或删除该环境变量:

# docker-compose.ymlservices:openclaw:image: openclaw:latest environment:# 方案 A:更新为正确的 Token- OPENCLAW_GATEWAY_TOKEN=正确的Token值 # 方案 B:直接删除此行,让配置文件生效# - OPENCLAW_GATEWAY_TOKEN=xxx ← 删除此行

修改完成后重启容器:

docker compose down &&docker compose up -d

五、彻底修复(停止 → 清除 → 重启)

如果以上快速修复方法都不奏效,可以执行完整的 Token 重置流程:

① 停止 Gateway → ② 清除旧 Token → ③ 启动 Gateway → ④ 重连 Agent 

Step 1:停止 Gateway 并确认已停止

# 原生部署 openclaw gateway stop ps aux |grep openclaw # Docker 部署docker compose stop dockerps|grep openclaw 

Step 2:清除旧 Token

删除每个 Agent 的 auth.json 文件中的 token 值。

注意

只删除 auth.json 中的 token 值,不要删除整个文件

Step 3:重新启动 Gateway

Gateway 在启动时会自动生成新的 Token。

openclaw gateway start 

Step 4:重新连接所有 Agent

Agent 首次连接时会自动获取并保存新 Token,无需手动操作。

💡 Docker 用户提示

日常重启推荐使用 docker compose restart;仅在需要全新容器状态时才使用 docker compose down && docker compose up -d

六、易混淆错误辨析

请注意区分以下两种 Token Mismatch 错误,它们的修复方式完全不同:

对比项Gateway Token MismatchDevice Token Mismatch
认证对象Agent → Gateway 的连接浏览器 / Control UI 会话
涉及配置gateway.auth.tokendevice.token
典型场景Gateway 重启、配置不同步更换浏览器、清除 Cookie
修复方式对齐 auth.token 和 remote.token重新打开 Dashboard URL

七、常用命令速查表

场景命令
🔧 自动诊断修复openclaw doctor --fix
🔑 查看当前 Gateway Tokenopenclaw config get gateway.auth.token
🔄 重新生成 Tokenopenclaw doctor --generate-gateway-token
🌐 打开带 Token 的 Dashboardopenclaw dashboard --no-open
📝 同步 Remote Tokenopenclaw config set gateway.remote.token "TOKEN"
♻️ 重启 Gatewayopenclaw gateway restart

八、总结

disconnected (1008): gateway token mismatch 错误的本质是 客户端与服务端持有的 Token 不一致。绝大多数情况下,通过以下三步即可快速解决:

  1. 首先尝试 openclaw doctor --fix 自动修复;
  2. 如未解决,检查配置文件中 auth.tokenremote.token 是否一致;
  3. Docker 用户额外检查环境变量 OPENCLAW_GATEWAY_TOKEN 是否存在覆盖。

如果上述方法均无效,执行完整的「停止 → 清除 → 重启」流程即可彻底解决。


🎉 希望本文对你有帮助!

如果解决了你的问题,请点赞 👍 收藏 ⭐ 关注 🔔,你的支持是我持续输出的动力!有问题欢迎在评论区留言交流~

Read more

Flutter 组件 calendar_time 的适配 鸿蒙Harmony 深度进阶 - 驾驭时间段语义隔离、实现鸿蒙端动态工作日排除与高并发列表动态刷新方案

Flutter 组件 calendar_time 的适配 鸿蒙Harmony 深度进阶 - 驾驭时间段语义隔离、实现鸿蒙端动态工作日排除与高并发列表动态刷新方案

欢迎加入开源鸿蒙跨平台社区:https://openharmonycrossplatform.ZEEKLOG.net Flutter 组件 calendar_time 的适配 鸿蒙Harmony 深度进阶 - 驾驭时间段语义隔离、实现鸿蒙端动态工作日排除与高并发列表动态刷新方案 前言 在前文中,我们利用 calendar_time 实现了基础的相对时间(如“刚才”、“昨天”)展示。但在真正的“金融级对账系统”、“政务排班大盘”或“高频社交动态”场景中。简单的相对描述远远不够。面对需要根据“当前业务时间”判定是否属于“法定工作时间”、针对包含上万条消息的列表如何实现高效的“每秒分钟数自增更新”。 如果处理不当,不仅会产生业务逻辑上的“时差错觉”。更会在鸿蒙(OpenHarmony)端引发严重的渲染性能雪崩。 本文将作为 calendar_time 适配的进阶篇。带你深入探讨其在鸿蒙端的逻辑时序对其、复杂区间判别(

By Ne0inhk

WSL needs updatingYour version of Windows Subsystem for Linux (WSL) is too old.如何解决

安装 Docker Desktop 时出现该问题,核心原因是:Docker Desktop 运行依赖 Windows Subsystem for Linux (WSL) 2 提供的轻量级虚拟化环境,而你的系统当前的 WSL 环境不符合运行要求。具体诱因主要有这三点: 1. WSL 功能未安装 / 版本过低:系统未启用 WSL 功能,或仅安装了旧版 WSL 1(Docker Desktop 硬性要求为 WSL 2 版本); 2. WSL 2 内核未更新:即便已安装 WSL 2,其内核组件未升级至最新版本,无法适配 Docker 运行需求; 3. 系统虚拟化功能未开启:Windows 未启用

By Ne0inhk
Flutter 组件 native_shuttle 的适配 鸿蒙Harmony 实战 - 驾驭极致原生通讯性能、实现鸿蒙端 Dart 与 ArkTS 之间的高频底层穿梭方案

Flutter 组件 native_shuttle 的适配 鸿蒙Harmony 实战 - 驾驭极致原生通讯性能、实现鸿蒙端 Dart 与 ArkTS 之间的高频底层穿梭方案

欢迎加入开源鸿蒙跨平台社区:https://openharmonycrossplatform.ZEEKLOG.net Flutter 组件 native_shuttle 的适配 鸿蒙Harmony 实战 - 驾驭极致原生通讯性能、实现鸿蒙端 Dart 与 ArkTS 之间的高频底层穿梭方案 前言 在鸿蒙(OpenHarmony)生态的极速动态图形交互、需要频繁调用系统底层多媒体能力以及对跨引擎数据同步有“毫秒级延时门禁”的各类专业级应用开发中,“宿主语言(ArkTS)与业务语言(Dart)之间的交互效率”是决定应用能否在大规模、高并发工况下保持流畅的终极技术壁垒。面对需要每秒传递 60 帧以上的高精度传感器数据流、复杂的 0307 批次资产二进制 Blob 同步或者是在鸿蒙平板与折叠屏之间执行频繁的逻辑状态投影。如果仅仅依靠传统的 MethodChannel 这种基于 JSON 或序列化编码的慢速异步通道。不仅会导致在数据转换(Serialization)过程中产生巨大的 CPU

By Ne0inhk

Flutter 三方库 persistent_cache_simple 的鸿蒙化适配指南 - 实现具备磁盘溢出淘汰与极简 API 的本地持久化缓存、支持端侧资源异步落地与状态秒开实战

欢迎加入开源鸿蒙跨平台社区:https://openharmonycrossplatform.ZEEKLOG.net Flutter 三方库 persistent_cache_simple 的鸿蒙化适配指南 - 实现具备磁盘溢出淘汰与极简 API 的本地持久化缓存、支持端侧资源异步落地与状态秒开实战 前言 在进行 Flutter for OpenHarmony 应用开发时,如何高效、持久地缓存一些网络 JSON、配置片段或临时计算结果?传统的 shared_preferences 在处理大段字符串时性能受限,且缺乏生命周期淘汰机制。persistent_cache_simple 是一款功能专一、基于文件系统的轻量级缓存库。本文将探讨如何在鸿蒙端构建极致、稳健的二级缓存体系。 一、原直观解析 / 概念介绍 1.1 基础原理 该库建立在“键值映射至文件(Key-to-File)”的简易架构之上。它利用鸿蒙应用的沙箱存储目录,将每一个缓存项序列化为独立的文件。

By Ne0inhk