1. 先搞清楚 1008 到底卡在哪一层访问http://localhost:18789直接弹红字disconnected (1008): unauthorized: gateway token missing这个报错在 OpenClaw也就是早期的 ClawdBot、MoltBot本地部署里出现频率极高。它的字面意思是WebSocket 握手阶段被网关拒绝原因是请求里没有携带有效的 gateway token。换句话说端口是通的、服务是活的但鉴权这一关没过。很多人第一反应是去翻配置文件其实没必要。OpenClaw 的网关默认开启 Token 授权这是设计上的安全机制不是 bug。你直接在浏览器地址栏敲localhost:18789浏览器不会自动带上任何凭证网关自然拒绝。真正要做的是拿到一个带 token 的访问链接或者把 token 填进 Control UI 的设置里。这个错误之所以让人头疼是因为它把三类问题混在同一个提示里端口没监听、鉴权缺失、反向代理链路断掉。如果你只盯着 token 看可能会忽略掉服务根本没起来的情况。所以排查顺序应该是从底层往上走——先确认 18789 有没有进程在听再确认 token 机制最后看反向代理有没有把 WebSocket 的 upgrade 头吃掉。我试过在一台 Ubuntu 22.04 上部署最新版Python 3.11.8一键命令装完浏览器一开就是 1008。当时也懵了几分钟后来按下面这套顺序逐层定位五分钟就恢复了。下面把每一步的命令和判断标准都写清楚你可以直接照着敲。先明确一点OpenClaw、ClawdBot、MoltBot 是同一个项目在不同时期的叫法命令主体可能从clawdbot变成moltbot再变成openclaw但网关端口 18789 和 token 授权逻辑是一致的。你遇到 1008 时先确认自己装的是哪个版本后面命令里的可执行文件名要对上。2. 端口监听与进程状态自查localhost:18789 到底有没有人听排查 1008 的第一步不是看 token而是确认 18789 端口有没有被监听。因为如果服务压根没起来浏览器同样会报连接失败只是错误码可能不同。但在某些封装下网关会先返回 1008 再断开容易误导你以为是鉴权问题。Linux 和 macOS 下用这条命令ss -tlnp | grep 18789或者用lsoflsof -iTCP:18789 -sTCP:LISTEN正常输出应该类似LISTEN 0 128 127.0.0.1:18789 0.0.0.0:* users:((openclaw,pid12345,fd7))这里有几个关键点要看。第一监听地址是127.0.0.1还是0.0.0.0。如果只监听127.0.0.1那你只能本机访问远程访问会失败但这不会导致 1008。第二进程名是不是 openclaw 或对应的可执行文件。第三如果这条命令没有任何输出说明服务没起来先去看日志别急着找 token。Windows 下用 PowerShellGet-NetTCPConnection -LocalPort 18789 -State Listen如果端口没监听先启动服务。一键安装的版本通常有 systemd 服务systemctl status openclaw systemctl start openclaw journalctl -u openclaw -n 50 --no-pager看日志里有没有gateway listening on 127.0.0.1:18789这类字样。如果日志里出现address already in use说明端口被别的进程占了换端口或者杀掉占用进程。这一步确认完才能进入 token 环节。还有一个容易忽略的点如果你是用 Docker 跑的端口映射可能只映射了 TCP 而没处理 WebSocket或者映射到了错误的容器端口。检查docker ps里的端口映射确认-p 18789:18789存在且容器内服务确实监听在这个端口。3. 可复制的鉴权配置生成带 token 的访问链接与统一 Key 接入确认端口在听之后1008 的核心就是 token 缺失。OpenClaw 提供了终端命令来生成带 token 的仪表盘链接。不同版本命令名不同先确认你的可执行文件which openclaw || which clawdbot || which moltbot然后执行openclaw dashboard --no-open如果你的是旧版把openclaw换成clawdbot或moltbot。执行后终端会输出一行带 token 的 URL格式类似http://127.0.0.1:18789/?token31943b8c90ea4f28b7a198xxxxxx把这个链接复制到浏览器打开1008 就会消失。注意 token 是每个实例随机生成的不要用别人的 token也不要把带 token 的截图发到公开仓库。如果你希望把 OpenClaw 接到统一的模型通道上而不是每个工具单独配 Key可以在网关配置里指定 Base URL 和 API Key。OpenClaw 的配置文件通常在~/.openclaw/config.toml或项目目录下的config.toml。下面是一个可复制的片段把模型通道指向 TaoToken 的统一入口[gateway] host 127.0.0.1 port 18789 auth_token auto [model] provider openai-compatible base_url https://taotoken.net/api api_key sk-你的TaoToken统一Key model_id claude-sonnet-4-20250514如果你用的是 JSON 配置部分版本支持settings.json对应写法{ gateway: { host: 127.0.0.1, port: 18789, authToken: auto }, model: { provider: openai-compatible, baseUrl: https://taotoken.net/api, apiKey: sk-你的TaoToken统一Key, modelId: claude-sonnet-4-20250514 } }这里三件套要写全Base URL 用https://taotoken.net/apiKey 用你在控制台生成的统一 KeyModel ID 填你实际要调用的模型。改完配置后重启服务systemctl restart openclaw如果你在 Cline、Codex 或 Claude Code 这类工具里也接了同一个通道记得它们的auth.json或 MCP 配置里的 Base URL 和 Key 保持一致避免一个工具能通、另一个报 401。TaoToken 的 API Key 可以在控制台创建接入文档里有各客户端的完整示例需要的话去 API Keys 页面拿 Key再对照接入文档改配置。4. 三步验证确认 1008 消除且请求真正走通配置改完不代表就通了要有明确的验证动作。下面三步按顺序做每步都有预期结果。第一步验证端口和 token 链接。重新执行openclaw dashboard --no-open拿到新链接后在浏览器打开按 F12 看 Console 和 Network。Network 里应该能看到一条 WebSocket 请求状态是 101 Switching Protocols而不是 1008。如果还是 1008说明 token 没生效检查配置文件里的auth_token是否被覆盖或者浏览器缓存了旧链接用无痕窗口再试。第二步用 curl 直接打网关的健康检查接口确认服务层正常curl -i http://127.0.0.1:18789/health预期返回 200 和一段 JSON。如果返回 401说明健康检查也需要 token那就带上 tokencurl -i http://127.0.0.1:18789/health?token你的token第三步验证模型通道是否真的能出结果。在 Control UI 里发一条最简单的消息比如「回复 ok」。如果 UI 里能正常返回说明网关鉴权和模型通道都通了。如果 UI 通了但模型报错看日志里有没有reading choices或401字样那说明是模型侧的 Key 或 Base URL 问题不是 1008 了。这三步做完基本可以确认 1008 已经消除。如果第三步卡住把日志里的具体报错记下来进入下一节的排查对照。5. 常见报错对照排查401、local proxy failed、reading choices、OAuth1008 解决后接下来容易撞上的是模型通道层的报错。下面按真实日志对照。401 unauthorized网关通了但模型 API Key 无效或过期。检查配置文件里的api_key是否和 TaoToken 控制台里的一致注意不要有多余空格。如果你用的是环境变量确认OPENAI_API_KEY或对应变量已经 export 且被服务读到。systemd 服务不会自动继承你 shell 里的环境变量要在 service 文件里用Environment显式声明。local proxy failed通常出现在你配了本地代理但代理没起来或者代理地址写错。检查配置里的 proxy 字段如果不需要代理就删掉。注意这里说的是本地转发配置不是网络层面的东西别混为一谈。reading choices或cannot read property choices of undefined这是模型返回体不符合预期格式。常见原因是 Base URL 指向了错误的路径比如少写了/v1或多写了/v1。TaoToken 的兼容入口是https://taotoken.net/api具体到 chat completions 的路径要按接入文档来。另一个原因是 Model ID 写错模型不存在时返回体里没有 choices 字段。OAuth相关报错如果你在 Claude Code 或 Codex 里用了 OAuth 登录方式又同时配了 API Key可能冲突。统一走 API Key 通道时把 OAuth 相关的 token 缓存清掉配置文件里只保留 Base URL Key Model ID 三件套。Codex 的auth.json里如果同时有 OAuth 和 API Key 字段以 API Key 为准或者直接删掉 OAuth 段。还有一个隐蔽的坑反向代理。如果你在 OpenClaw 前面挂了 Nginx 或 CaddyWebSocket 的 upgrade 头可能被吃掉表现也是 1008 或连接断开。Nginx 需要显式配置location / { proxy_pass http://127.0.0.1:18789; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection upgrade; proxy_set_header Host $host; }少了Upgrade和Connection这两行WebSocket 握手就会失败。Caddy 一般自动处理但如果你手动改了 header 也可能出问题。6. 把通道固定下来长期编码场景的接入建议1008 这类问题本质上是本地网关鉴权和模型通道配置没对齐。单次修好不难难的是每次换工具、换项目都要重新配一遍。如果你经常在 OpenClaw、Cline、Claude Code 之间切换建议把模型通道统一到一个入口所有工具都指向同一个 Base URL 和 Key这样排查时只需要看一个地方。具体做法是在 TaoToken 控制台创建一个统一 Key然后在每个工具的配置里都填https://taotoken.net/api作为 Base URLModel ID 按需选择。OpenClaw 的config.toml、Cline 的 MCP 配置、Codex 的auth.json、Claude Code 的 settings 都保持这三件套一致。这样任何一个工具报 401 或 reading choices你只需要检查这一个 Key 和这一个 Base URL不用在多个配置之间来回对照。如果你主要做长期编码或 Agent 类任务可以考虑用 Coding Plan 把额度和通道固定下来避免频繁换 Key 导致配置漂移。需要看模型实际返回效果时模型对话页面可以直接验证通道是否正常不用每次都启动 OpenClaw。接入文档里有各客户端的完整配置示例照着改就行。最后提醒一句gateway token 和模型 API Key 是两回事。前者是 OpenClaw 本地控制台的访问凭证后者是模型通道的鉴权。1008 是前者的问题401 是后者的问题别搞混。把这两层分清楚以后遇到任何报错都能快速定位到是哪一层。