有些问题真的很会“伪装”。

    跟着热点去升级openclaw后，Chrome 的扩展插件一直提示 Gateway token rejected，第一眼看过去，几乎所有人都会先怀疑 token 填错了。我们当时也是这么想的。

   结果一路排下来，发现 token 文本并不是主因。真正的问题是：请求打到了错误的服务端口。

事情是怎么发生的

    现场环境里同时跑了两套 OpenClaw：默认 profile 和 guest profile。
默认 profile 的 Chrome extension relay 本来应该监听 127.0.0.1:18792。但这个端口先被 guest 占了，默认 relay 启动失败。

于是就出现了一个很迷惑的现象：

• 扩展里填的是默认 profile 的 token（看起来没问题）
• 但请求没进默认 relay，而是进了别的服务
• 最终扩展只给出统一提示：Gateway token rejected

所以这次故障的本质原因不是“凭证错误”，而是“目标服务错误”。

最容易踩的坑：ai在处理过程中，把 18791 当成扩展端口

排查时很容易看到 127.0.0.1:18791 在监听，然后下意识拿它去试扩展。
问题是 18791 通常是 browser control，不是 extension relay。

两者鉴权头也不一样：

• browser control：Authorization: Bearer <token>
• extension relay：x-openclaw-relay-token

扩展如果连到 18791，出现 401 其实很正常。

证据怎么闭环

我们当时抓到的关键证据很直接：

1. 默认 profile 日志反复出现 EADDRINUSE ... 127.0.0.1:18792
2. lsof
   
    能看到 guest 进程在监听 18792 / 18793
3. 18791 探测返回 401，和扩展 relay 的行为不一致

这三条串起来，基本就坐实了：默认 relay 被抢端口，扩展请求打偏了。

临时修复（先恢复服务）

openclaw --profile guest gateway stop
openclaw gateway restart

执行后，默认 profile 同时监听 18791 与 18792，扩展恢复正常。

扩展正确配置应为：

• Port：18792
• Token：默认 profile 的 gateway.auth.token

长期方案（防复发）

如果两套实例要长期并行，端口必须彻底错开。
我们落地后的规划是：

• 默认 profile：18789 / 18791 / 18792
• guest profile：18890 / 18892 / 18893

这样就不会再出现 guest 抢占默认 relay 端口的问题。

---

解决后的经验总结：
看到 Gateway token rejected，先别急着重抄 token，第一步应该是查端口归属和请求到底落到哪个服务。

---

V2｜工程师实战帖（社区发帖）

踩坑记录：Gateway token rejected 不一定是 token 错

今天这个坑，真的很典型。
扩展一直报 Gateway token rejected，我一开始也死盯 token，来回核对好多次——结果方向全错。

真相是端口冲突。

我们机器上同时跑默认 profile 和 guest profile。默认扩展 relay 应该用 18792，但被 guest 先占了。默认 relay 起不来，扩展拿着“正确 token”去敲“错误服务”，最后就被统一报成 token rejected。

这里有个高频误区：
18791 ≠ 扩展 relay 端口。

• 18791 多数是 browser control
• 18792 才是默认扩展 relay
• 鉴权头也不是一套（Bearer vs relay token）

所以你把扩展指到 18791，拿到 401 一点都不奇怪。

我这边的临时修复就两条命令：

bashCopyCopied!

openclaw --profile guest gateway stop
openclaw gateway restart

然后扩展配置回到：

• Port：18792
• Token：默认 profile 的 gateway.auth.token

为防止后面再中招，直接把 guest 端口平移到：

• 18890 / 18892 / 18893

彻底和默认实例错开。