1. 启动 OpenClaw 后为什么冒出两个端口你第一次把 OpenClaw 跑起来大概率会盯着终端里那两行监听日志发愣一个 18789一个 18792。浏览器插件那边要填一个 Relay Port配置文件里又写着 Gateway Port两个数字还不一样。很多人第一反应是「是不是配错了」「是不是端口冲突了」然后开始乱改结果插件连不上、浏览器也控制不了。OpenClaw 能做什么简单说它是一个让 AI 代理去操作浏览器的本地服务框架。适合谁适合想把大模型接到真实浏览器动作上的开发者比如自动填表、抓页面、点按钮、截图这类活儿。它启动后出现两个监听端口不是 bug而是它把「大脑」和「手」拆成了两个进程来跑。我试过把这套东西拆开看结论很清晰一个端口负责协调和鉴权另一个端口专门说 Chrome DevTools Protocol 的话。前者是 Gateway后者是 CDP。你只要理解这两个角色的分工配置文件里那些端口字段就全对上了。这篇就按「进程模型 → 通信分层 → 配置对应 → 连通性验证」的顺序把两个端口背后的设计逻辑讲透并给出可以直接复制的 config.toml 骨架和验证命令。2. TaoToken 前置统一 Key 与 API 通道在讲端口之前先把模型侧的事情理清楚。OpenClaw 本身不生产模型能力它要调用外部大模型来完成推理和工具决策。这里用 TaoToken 做统一入口会比较省心一个 Key 走通模型对话、编码计划和 API 通道不用在多个平台之间来回切换配置。TaoToken 的定位是统一的大模型 API 接入层。你可以把它理解成一个「总机」OpenClaw 的 Gateway 需要模型能力时向这个总机发请求总机再路由到具体模型。对本地服务来说你只需要维护一份 Key 和一个 base_url配置复杂度直接降下来。具体入口如下按需取用官网地址https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentAPI 通道https://taotoken.net/api模型对话验证模型是否通https://taotoken.net/models?utm_sourcetaotoken_aicg_blog_endutm_contentmodelsutm_campaignrewriteCoding Plan长期编码 / Agent 场景https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding-planutm_campaignrewrite控制台https://taotoken.net/console?utm_sourcetaotoken_aicg_blog_endutm_contentconsoleutm_campaignrewriteAPI Keys 管理https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi-keysutm_campaignrewrite接入文档https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewriteClaudeCodeAnthropic 接入https://taotoken.net/claudecode-anthropic?utm_sourcetaotoken_aicg_blog_endutm_contentclaudecode-anthropicutm_campaignrewrite注意模型侧的 Key 和 OpenClaw 本地的 Gateway Token 是两回事。前者是访问大模型服务的凭证后者是保护你本机 Gateway 端口的令牌。别把两个 Token 填串了这是新手最常见的坑之一。拿到 Key 之后先别急着配 OpenClaw。你可以先用模型对话页面确认这个 Key 能正常出结果再去动本地配置文件。顺序反了的话出问题你分不清是模型侧还是端口侧。3. 两个端口的进程模型与通信分层3.1 Gateway 端口大脑与总调度Gateway 是 OpenClaw 的主控制中心默认监听 18789。它承担的事情包括提供本地 Web UI 控制面板、处理内部 API 请求、管理对话会话和代理会话、路由来自不同频道的消息、调度工具命令、以及最关键的——验证访问令牌。它的协议是 HTTP 加 WebSocket属于通用协议。你可以在浏览器里直接打开http://127.0.0.1:18789看到控制面板这说明它对外暴露的是一个标准的 Web 服务。认证模式通常是 token绑定在 loopback 上也就是只允许本机访问。一句话概括Gateway 是「大脑」所有业务逻辑和协调都从这里过。3.2 CDP 端口手与浏览器控制CDP 全称 Chrome DevTools Protocol默认监听 18792。它只干一件事通过 CDP 协议控制 Chrome 浏览器。具体能力包括获取和切换标签页、页面截图、读取和修改 DOM、模拟点击和键盘输入、打开 URL 和前进后退。它的协议是纯 WebSocket访问地址形如ws://127.0.0.1:18792/cdp。它本身没有独立的认证安全性依赖 Gateway 和 loopback 绑定。也就是说CDP 不直接对外它是被 Gateway 调用的「执行层」。一句话概括CDP 是「手」专门操作浏览器。3.3 为什么必须拆成两个端口职责分离是第一层原因。Gateway 管协调和业务CDP 管浏览器控制两者混在一起会让代码边界模糊。独立运行是第二层原因CDP 服务可以单独启停浏览器控制崩了不会拖垮核心服务。协议不同是第三层原因Gateway 用通用 HTTP/WebSocketCDP 用纯 WebSocket 做实时双向通信。安全性是第四层原因Gateway 有 Token 保护CDP 只让本地扩展连。对比项GatewayCDP默认端口1878918792协议HTTP / WebSocketWebSocket职责核心服务、调度、鉴权浏览器控制认证Token 验证无依赖 Gateway绑定loopbackloopback3.4 一次「打开浏览器点赞」的完整链路当你在对话里说「打开浏览器点赞这条推文」消息的流向是这样的你的消息先进入 Gateway18789Gateway 路由到 agentagent 决定调用 browser 工具工具请求转发到 CDP 服务18792CDP 再通过 Chrome Relay 扩展把动作落到真实浏览器上。链路是单向分层的Gateway 不直接碰浏览器CDP 不直接做业务决策。两个端口各司其职这就是双端口设计的核心。4. 可复制的 config.toml 骨架与端口字段对应下面这份骨架可以直接拿去改。重点看gateway.port和browser.cdpPort两个字段它们分别对应你终端里看到的那两个监听端口。# OpenClaw 本地配置骨架 # 端口字段与启动日志中的两个监听端口一一对应 [gateway] # 大脑主控制中心对应终端里的 18789 port 18789 bind loopback # 仅本机访问别改成 0.0.0.0 auth_mode token gateway_token 你的本地Gateway令牌 # 与模型Key无关 [gateway.model] # 模型侧统一走 TaoToken provider taotoken base_url https://taotoken.net/api api_key 你的TaoToken Key model 你的模型名 [browser] # 手浏览器控制对应终端里的 18792 cdp_port 18792 cdp_url http://127.0.0.1:18792 relay_port 18792 # 插件里填的 Relay Port 与此一致 enabled true [browser.chrome] # Chrome 以调试模式启动时暴露的端口注意与 cdp_port 区分 remote_debugging_port 18792几个容易搞混的点单独拎出来说gateway.port是 Gateway 的监听端口插件配置里的「Gateway 地址」要填这个。browser.cdp_port是 CDP 服务端口插件里的「Relay Port」要填这个。remote_debugging_port是 Chrome 自己暴露调试接口的端口通常和 CDP 端口保持一致但概念上不是同一个东西。提示如果你把bind改成了非 loopback等于把本地服务暴露到局域网务必确认你清楚后果。默认的 loopback 是最安全的做法。5. 验证两个端口的连通性与成功结果配置写完后别急着开插件。先用命令行确认两个端口各自活着而且职责正确。5.1 确认端口在监听# 查看两个端口是否处于 LISTEN 状态 lsof -iTCP:18789 -sTCP:LISTEN lsof -iTCP:18792 -sTCP:LISTEN预期结果18789 那行显示 OpenClaw 的主进程18792 那行显示 CDP 相关进程。如果某个端口没有输出说明对应服务没起来。5.2 验证 Gateway 的 HTTP 服务# Gateway 是 HTTP 服务直接请求根路径 curl -i http://127.0.0.1:18789/预期结果返回 200 或 401。返回 401 说明服务活着只是需要 Token这反而是正常的。如果连接被拒绝说明 Gateway 没启动。5.3 验证 Gateway 的 Token 鉴权# 带上 Token 请求确认鉴权通道可用 curl -i -H Authorization: Bearer 你的本地Gateway令牌 \ http://127.0.0.1:18789/预期结果返回 200说明 Token 正确、鉴权链路通。5.4 验证 CDP 的 WebSocket 端点# CDP 是 WebSocket先看 HTTP 探测是否响应 curl -i http://127.0.0.1:18792/cdp预期结果返回 400 或 426 这类「协议不匹配」的响应说明端口活着、只是不接受普通 HTTP。如果直接连接被拒绝说明 CDP 没起来。# 用 websocat 做一次真正的 WebSocket 握手需先安装 websocat websocat ws://127.0.0.1:18792/cdp预期结果握手成功并保持连接说明 CDP 的 WebSocket 通道可用。5.5 验证模型侧通道# 确认 TaoToken 的 API 通道可达 curl -i https://taotoken.net/api预期结果返回正常的 HTTP 响应。这一步是确认模型侧网络没问题和本地端口是两条独立的链路。把上面五步跑完你就能明确知道18789 是 Gateway 在听18792 是 CDP 在听模型侧走 TaoToken 的 API 通道。三者互不干扰各管一段。6. 本篇常见错排查6.1 插件填错端口导致连不上最常见的错误是把 Relay Port 填成了 18789。记住插件里的 Relay Port 对应 CDP 端口 18792Gateway 地址才对应 18789。填反了插件会一直转圈。6.2 两个 Token 混用Gateway Token 是保护本地端口的TaoToken Key 是访问模型服务的。把 TaoToken Key 填进gateway_token或者反过来都会导致鉴权失败。分开管理别图省事。6.3 端口被占用如果启动时报端口占用先查是谁占了lsof -iTCP:18789 -sTCP:LISTEN lsof -iTCP:18792 -sTCP:LISTEN确认是残留进程就清掉是别的服务就改 OpenClaw 的端口同时记得同步改插件里的 Relay Port。6.4 bind 改成非 loopback 后连不上有些人为了「让别的机器也能访问」把 bind 改成 0.0.0.0结果插件反而连不上。原因是 CDP 和扩展的握手依赖本地回环。除非你明确知道自己在做什么否则保持 loopback。6.5 CDP 端口活着但浏览器没反应CDP 端口能连上不代表 Chrome 一定被控制住了。检查 Chrome 是否以调试模式启动、remote_debugging_port是否和 CDP 端口一致、Relay 扩展是否已加载。这三者缺一个链路就断在浏览器那一环。6.6 模型侧报错却去查端口如果 Gateway 和 CDP 都正常但对话没结果问题多半在模型侧。这时候去模型对话页面单独验证 Key或者查接入文档确认 base_url 和模型名。别在端口上浪费时间。排障顺序建议固定下来先确认两个端口在听再确认 Gateway 鉴权通再确认 CDP 握手通最后才查模型侧。按这个顺序走能省掉大量来回试错。如果你在接入阶段卡住优先看 API Keys 管理和接入文档如果只是想确认模型能不能出结果直接用模型对话页面验证如果是长期跑编码或 Agent 任务Coding Plan 会更合适。把本地双端口的职责理清再把模型通道接稳OpenClaw 这套东西就能真正跑起来。