1. OpenClaw Gateway 报错现场还原401 与 local proxy failed 到底卡在哪一环OpenClaw Gateway 是一个把本地 AI 工具、聊天通道和模型服务串起来的中间层它负责转发请求、管理通道账号、校验令牌。你如果正在用 OpenClaw 接飞书、接 Claude Code、接 Cline 这类工具大概率会碰到两类报错一类是401 unauthorized另一类是local proxy failed。这两个错误看起来都像连不上但触发位置完全不同排查顺序错了就会一直在原地打转。先说 401。它的本质是认证没通过请求已经到达了 Gateway但 Gateway 认为你手里的令牌不对。典型报错长这样gateway disconnected: unauthorized: gateway token mismatch (provide gateway auth token) gateway connect failed: Error: unauthorized: gateway token mismatch (provide gateway auth token)注意关键词token mismatch它不是没有 token而是两个 token 对不上。OpenClaw 里有两个容易混淆的令牌gateway.auth.token是网关服务自己用的gateway.remote.token是客户端连接时用的。很多人只配了前者后者留空于是客户端拿着空令牌去连网关拿自己的令牌一比直接 401。再说local proxy failed。这个错误的触发点更靠前通常出现在客户端尝试通过本地代理端口转发请求时。报错形态类似local proxy failed: dial tcp 127.0.0.1:18789: connect: connection refused local proxy failed: context deadline exceededconnection refused说明端口上根本没有进程在监听网关没起来或者崩了context deadline exceeded说明端口有进程但没响应可能是进程卡死或者被防火墙拦了。还有一种更隐蔽的端口被别的程序占用你的请求发过去被别人接了返回一堆看不懂的东西最终在客户端表现为reading choices解析失败。reading choices这个报错值得单独说。它一般出现在 OpenAI 兼容接口的响应解析阶段客户端期望拿到choices数组结果拿到的是 HTML 错误页、空响应或者非标准 JSON。常见原因有三个Base URL 配错导致请求打到了网页而不是 API模型 ID 写错导致服务端返回错误结构代理层把错误响应原样透传客户端解析时炸掉。我试过把这三类错误按请求链路排一遍顺序是这样的先确认 Gateway 进程活着且端口在听再确认令牌一致最后确认客户端到 Gateway 的 Base URL 和模型 ID 正确。这个顺序能覆盖 90% 的场景因为链路上游不通下游怎么调都是白费。适合谁看这篇正在 Windows 上跑 OpenClaw 2026.2.x、接了飞书通道或者本地 AI 工具、被 401 和 local proxy failed 卡住的同学。下面我会把每个环节的配置片段和验证命令都给全你可以直接复制改。2. TaoToken 前置准备Base URL、Key 与 Model ID 三件套怎么配在动 OpenClaw 的配置之前先把模型服务这一层理顺。OpenClaw Gateway 本身不产出模型能力它是个转发和调度层真正干活的是背后的模型 API。如果你用的是 TaoToken 这类兼容 OpenAI 协议的服务需要准备好三样东西Base URL、API Key、Model ID。这三件套缺一个后面就会以reading choices或者 401 的形式报出来。Base URL 是请求的根地址。TaoToken 的 API 入口是https://taotoken.net/api注意这里不要带任何多余路径客户端会自动拼接/v1/chat/completions这类后缀。很多人手滑写成https://taotoken.net/api/v1结果客户端再拼一次/v1变成/api/v1/v1/chat/completions服务端返回 404客户端解析失败报reading choices。API Key 在控制台的 API Keys 页面生成格式通常是一串以sk-开头的字符串。生成后立刻复制保存页面刷新后就不再完整显示。Key 要填到 OpenClaw 的模型配置里不是填到 Gateway 的 auth token 里这两个是完全不同的东西混填是 401 的常见来源。Model ID 要跟你实际调用的模型对齐。比如你想用 Claude 系列就填对应的模型标识想用 GPT 系列就填另一套。Model ID 写错时服务端一般返回model not found但如果代理层做了兜底可能返回一个空choices客户端就报reading choices。所以 Model ID 一定要从文档里抄别凭记忆写。把这三件套整理成一张对照表方便你填配置时核对配置项值示例填错的表现Base URLhttps://taotoken.net/api404 或 reading choicesAPI Keysk-xxxxxxxx401 unauthorizedModel ID按文档填写model not found 或空 choices如果你还没生成 Key可以去控制台的 API Keys 页面创建入口是https://taotoken.net/console/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi_keysutm_campaignrewrite。创建时给 Key 起个能认出来的名字比如openclaw-gateway方便后面排查时区分是哪个客户端在用。配好三件套后建议先用最简方式验证一次别急着往 OpenClaw 里塞。用 curl 直接打一发curl -X POST https://taotoken.net/api/v1/chat/completions \ -H Authorization: Bearer sk-你的KEY \ -H Content-Type: application/json \ -d { model: 你的ModelID, messages: [{role: user, content: ping}] }如果返回里有choices数组说明三件套没问题可以进入 OpenClaw 配置环节。如果返回 401检查 Key 有没有多余空格如果返回 404检查 Base URL 有没有多写/v1如果返回空或者 HTML检查是不是请求打到了网页。这一步过了后面 OpenClaw 的报错就基本能锁定在 Gateway 自身配置上。3. 可复制配置openclaw.json 里 Gateway 与通道的完整片段OpenClaw 的主配置文件在 Windows 上是C:\Users\用户名\.openclaw\openclaw.json。这个文件同时管通道channels和网关gateway两块配置出问题会分别对应不同的报错。下面给一份可以直接改的完整片段路径和字段名跟 OpenClaw 2026.2.x 保持一致。先看通道部分。飞书通道最常见的坑是账户名。配置里如果写的是accounts.main而绑定规则默认匹配default启动时就会报channels.feishu: accounts.default is missing and no valid account-scoped binding exists for configured accounts (main). Channel-only bindings (no accountId) match only default. Add bindings[].match.accountId for one of these accounts (or *), or add channels.feishu.accounts.default.解决办法是把main改成default或者补一条 accountId 绑定。最省事的是直接改名{ channels: { feishu: { enabled: true, accounts: { default: { appId: cli_你的APPID, appSecret: 你的APPSECRET } } } } }再看网关部分。这里的关键是auth.token和remote.token必须一致。auth.token是网关服务启动时用的remote.token是客户端连接时用的。只配一个另一个留空就会 401 token mismatch。完整片段{ gateway: { port: 18789, mode: local, bind: loopback, auth: { mode: token, token: 你的TOKEN }, remote: { token: 你的TOKEN } } }把两块合起来就是一份能跑的openclaw.json骨架{ channels: { feishu: { enabled: true, accounts: { default: { appId: cli_你的APPID, appSecret: 你的APPSECRET } } } }, gateway: { port: 18789, mode: local, bind: loopback, auth: { mode: token, token: 你的TOKEN }, remote: { token: 你的TOKEN } } }如果你用的是 Claude Code 或者 Cline 这类客户端它们的配置里也要填三件套。以 Claude Code 的 settings 为例Base URL 指向 TaoToken 的 API 入口Key 填 API KeyModel ID 填对应模型{ env: { ANTHROPIC_BASE_URL: https://taotoken.net/api, ANTHROPIC_API_KEY: sk-你的KEY, ANTHROPIC_MODEL: 你的ModelID } }Cline 的 MCP 配置类似在cline_mcp_settings.json里写{ mcpServers: { taotoken: { command: npx, args: [-y, 你的MCP包], env: { BASE_URL: https://taotoken.net/api, API_KEY: sk-你的KEY, MODEL_ID: 你的ModelID } } } }Codex 的auth.json则是另一套结构核心也是 Base URL、Key、Model ID 三件套{ base_url: https://taotoken.net/api, api_key: sk-你的KEY, model: 你的ModelID }配置改完别急着重启先用openclaw config get把关键字段读出来核对一遍openclaw config get gateway.auth --show-secrets openclaw config get gateway.remote --show-secrets如果两个 token 打印出来一致说明配置层没问题。如果remote是空的那就是 401 的根因补上再重启。4. 逐项验证从 gateway status 到实际请求的成功结果配置写完进入验证环节。验证要按链路顺序来从进程到端口从端口到令牌从令牌到实际请求。每一步都有明确的成功标志任何一步不对就停下来修别跳步。第一步看网关整体状态openclaw gateway status正常输出类似Runtime: running (last run time 2026/2/27 10:47:26) RPC probe: ok Listening: 127.0.0.1:18789这里有个容易误判的点如果显示Runtime: stopped但RPC probe: ok说明网关进程其实在跑只是不是通过 Windows 计划任务启动的。功能正常不影响使用不用慌。真正要警惕的是RPC probe: failed那才是进程没起来或者端口不通。第二步确认端口在监听netstat -ano | findstr :18789正常会看到一行LISTENING后面跟 PID。如果什么都没有说明网关没起来回到上一步看日志。如果看到多个 PID 抢同一个端口那就是端口冲突需要taskkill /PID pid /F干掉多余的。第三步看日志确认通道和网关都起来了。日志位置在C:\Users\用户名\AppData\Local\Temp\openclaw\openclaw-YYYY-MM-DD.log正常日志里应该有listening on ws://127.0.0.1:18789 (PID 34780) feishu[default]: WebSocket client started ws client ready如果看到feishu[main]而不是feishu[default]说明通道账户名还没改过来回到第 3 节改配置。第四步实际发一个请求验证端到端。用 curl 打 Gateway 的本地端口或者直接用客户端发一条消息。成功标志是收到带choices的 JSON 响应{ choices: [ { message: { role: assistant, content: pong } } ] }如果这一步返回 401说明令牌还是不一致回去核对auth.token和remote.token。如果返回local proxy failed说明请求根本没到 Gateway检查端口和进程。如果返回空或者 HTML说明 Base URL 或 Model ID 有问题回到第 2 节用 curl 直连验证。第五步验证飞书通道。改完账户名后跑openclaw status输出里应该看到Feishu: OK。如果还是报accounts.default is missing说明配置没生效可能是改错了文件或者没重启。重启命令openclaw gateway restart五步走完链路就通了。整个过程的核心思路是先确认进程和端口再确认令牌最后确认模型三件套。顺序反了就会在 401 和 local proxy failed 之间反复横跳。5. 常见报错对照排查401、local proxy failed、reading choices 逐个拆这一节把三个高频报错单独拎出来每个都给触发条件、排查动作和修复方式。你可以对着自己的报错直接跳。401 unauthorized / gateway token mismatch触发条件gateway.auth.token和gateway.remote.token不一致或者remote.token压根没设。排查动作openclaw config get gateway.auth --show-secrets openclaw config get gateway.remote --show-secrets两个输出对比不一致就是根因。修复方式优先用非管理员方案openclaw config set gateway.remote.token 你的TOKEN openclaw gateway restart如果config set不生效再考虑重装服务需要管理员权限openclaw gateway install --force注意重装是下策因为它会重置一些状态能用config set解决就别重装。local proxy failed: connection refused触发条件客户端尝试连127.0.0.1:18789但端口上没有进程监听。排查动作openclaw gateway status netstat -ano | findstr :18789如果 status 显示 stopped 且 netstat 没输出说明网关没起来。看日志找原因type C:\Users\用户名\AppData\Local\Temp\openclaw\openclaw-2026-02-27.log常见原因是配置文件 JSON 语法错误导致启动失败比如多了个逗号或者少了引号。用 JSON 校验工具过一遍openclaw.json。修复方式openclaw gateway restart如果重启后还是 refused检查端口有没有被占用netstat -ano | findstr :18789 taskkill /PID 占用PID /F openclaw gateway restartlocal proxy failed: context deadline exceeded触发条件端口有进程但请求超时没响应。常见于进程卡死或者防火墙拦截。排查动作先看进程是否响应 RPCopenclaw gateway status如果RPC probe: failed说明进程卡死。直接杀掉重启openclaw gateway stop taskkill /PID pid /F openclaw gateway restart如果 RPC 正常但还是超时检查 Windows 防火墙有没有拦18789端口。本地 loopback 一般不受防火墙影响但如果你把bind改成了非 loopback就可能被拦。reading choices 解析失败触发条件客户端期望choices数组实际拿到非标准响应。根因通常在模型服务层不在 Gateway。排查动作绕过 Gateway用 curl 直连模型 APIcurl -X POST https://taotoken.net/api/v1/chat/completions \ -H Authorization: Bearer sk-你的KEY \ -H Content-Type: application/json \ -d {model:你的ModelID,messages:[{role:user,content:ping}]}如果 curl 也报错问题在 Base URL、Key 或 Model ID。如果 curl 正常但客户端报错问题在客户端的配置检查它的 Base URL 有没有多写/v1Model ID 有没有写错。修复方式Base URL 统一用https://taotoken.net/api不要带/v1Model ID 从文档抄Key 检查有没有多余空格。把三个报错和对应动作整理成速查表报错根因层首选动作401 token mismatchGateway 令牌设 remote.token 并重启local proxy failed refused进程/端口重启网关查端口占用local proxy failed timeout进程卡死/防火墙杀进程重启查 bind 配置reading choices模型三件套curl 直连验证 Base URL/Key/Model排查时记住一个原则报错信息里的关键词指向哪一层就先查哪一层。token指向认证层proxy指向网络层choices指向模型响应层。按这个分层去查比盲目重启快得多。6. 把链路跑通之后日常维护与下一步动作链路跑通之后日常维护其实就三件事看状态、看日志、备份配置。状态用openclaw status和openclaw gateway status日志在C:\Users\用户名\AppData\Local\Temp\openclaw\下按日期分文件配置备份就是把openclaw.json复制一份改名存好。这三件事花不了几分钟但能在出问题时省下大量排查时间。有个细节值得注意Runtime: stopped但RPC probe: ok这个状态组合很多人第一次见会以为网关挂了其实它只是没通过计划任务启动。功能完全正常不用管它。真正要处理的是RPC probe: failed那才是进程层面的问题。如果你后面要接更多客户端比如 Claude Code、Cline、Codex记住每个客户端都要配齐 Base URL、Key、Model ID 三件套。Base URL 统一用https://taotoken.net/apiKey 从控制台生成Model ID 按文档填。三件套里任何一个写错都会以reading choices或 401 的形式暴露出来排查方法跟第 5 节一样。需要生成新的 API Key 时去控制台的 API Keys 页面操作入口是https://taotoken.net/console/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi_keysutm_campaignrewrite。接入文档在https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite里面有各客户端的配置示例遇到不确定的字段名可以去对一下。想先验证模型通不通可以用模型对话页面直接发消息测试入口是https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_contentmodel_chatutm_campaignrewrite。如果你是要长期跑编码任务或者 Agent 工作流Coding Plan 会比按量调用更省心入口在https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding_planutm_campaignrewrite。它适合那种每天都要跑很多次请求、又不想每次盯着余额的场景。最后留一个实用习惯每次改完openclaw.json先跑一遍 JSON 校验再重启。语法错误是local proxy failed: connection refused最常见的隐藏原因因为网关启动时解析配置失败会直接退出端口自然就没人听了。校验命令可以用 Python 一行搞定python -m json.tool C:\Users\用户名\.openclaw\openclaw.json输出格式化后的 JSON 就说明语法没问题报错就按提示的行号去改。这个习惯能帮你避开一大半配置看起来对但就是起不来的坑。