1. 为什么 Ubuntu 上的 OpenClaw 连不上 Windows 的 Chrome先说清楚这套链路到底在解决什么问题。你在 Ubuntu 上跑 OpenClaw想让它去操作另一台 Windows 机器上的 Chrome 浏览器做自动化点击、截图、抓取页面快照这类事情。听起来简单但真动手就会发现OpenClaw 默认的浏览器配置是给「本机浏览器」用的跨机器根本连不上。核心矛盾在于 Chrome 的调试协议 CDPChrome DevTools Protocol默认只监听 127.0.0.1也就是只有本机能访问。你在 Windows 上开了--remote-debugging-port9222Ubuntu 那边curl http://windows-ip:9222/json/version大概率是超时或者拒绝连接。这不是 OpenClaw 的问题也不是 Chrome 的问题是网络层和监听地址的问题。我试过直接在 OpenClaw 里填cdpUrl: http://192.168.x.x:9222结果一直报连接失败。后来才搞明白Chrome 那个--remote-debugging-address0.0.0.0参数在很多版本上并不真正生效它还是绑在 127.0.0.1 上。所以你需要一个中间层把 Windows 本机的 9222 端口转发成一个局域网可访问的端口这就是 portproxy 出场的地方。整套架构长这样Ubuntu OpenClaw - http://Windows局域网IP:13333 - Windows portproxy (监听 0.0.0.0:13333) - 127.0.0.1:9222 - Chrome DevTools Protocol - Windows Chrome 实例这里有两个关键端口要分清楚9222 是 Chrome 本机的 CDP 调试端口只给本机用13333 是 Windows 对局域网开放的转发端口给 Ubuntu 的 OpenClaw 用。很多人一上来就把 9222 暴露出去结果要么被占用要么防火墙拦死要么 Chrome 根本没监听成功。还有一个容易踩的坑跨机器场景下不要用existing-session或者profileuser。那种模式适合同一台机器上 OpenClaw 直接附着本机浏览器跨机器必须走 remote CDP。你需要在 OpenClaw 配置里明确写cdpUrl指向转发后的地址而不是指望它自动发现。另外给 OpenClaw 单独养一个 Chrome profile 目录是个好习惯。比如C:\chrome-openclaw-profile第一次你手动登录需要的网站cookie 和登录态就存在这个目录里。以后 OpenClaw 连的还是这个 profile既有登录态又不污染你日常用的主浏览器。说白了就是给自动化单独开一个「有记忆的浏览器」。这一节先把问题和架构讲透下一节说 TaoToken 在这套链路里扮演什么角色以及怎么把模型调用通道统一起来。2. TaoToken 前置准备统一 Key 与 API 通道OpenClaw 本身是个浏览器自动化框架但它在执行任务时往往需要调用大模型来做决策、解析页面、生成操作序列。如果你每个模型都单独配一套 Key管理起来会很乱。TaoToken 在这里的作用就是把模型调用统一到一个 API 通道上一个 Key 走天下。先明确一点TaoToken 不是让你绕过什么它是一个正常的 API 聚合服务官网在 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content API 入口是 https://taotoken.net/api 。你注册后在控制台生成 Key然后把这个 Key 填到 OpenClaw 的模型配置里就行。具体要准备的东西第一一个 TaoToken 的 API Key。去控制台 https://taotoken.net/console?utm_sourcetaotoken_aicg_blog_endutm_contentconsoleutm_campaignrewrite 创建复制出来备用。这个 Key 就是你所有模型调用的通行证。第二确认你要用的模型 ID。TaoToken 支持多种模型你在模型对话页面 https://taotoken.net/models?utm_sourcetaotoken_aicg_blog_endutm_contentmodelsutm_campaignrewrite 能看到可用列表。记下你要用的那个 Model ID比如某个 Claude 或者 GPT 系列的标识符。第三OpenClaw 的配置文件位置。在 Ubuntu 上通常是~/.openclaw/openclaw.json。你要在这个文件里同时配好浏览器 remote CDP 和模型 API 两块。为什么要把模型通道也统一到 TaoToken因为 OpenClaw 做浏览器自动化时经常需要模型来理解页面结构、决定点哪个按钮、填什么内容。如果模型 API 不稳定或者 Key 分散整个自动化链路就会断。统一到一个通道后你只需要维护一个 Key换模型也只改一个 Model ID。这里要提醒TaoToken 的 Base URL 是https://taotoken.net/api不要加多余的路径。Key 放在 Authorization 头里格式是Bearer 你的Key。Model ID 按你实际选的填。这三件套Base URL Key Model ID在 OpenClaw 的模型配置段里要写全缺一个都会报 401 或者 model not found。如果你用的是 Claude Code 或者类似的编码工具TaoToken 也有对应的接入方式文档在 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite 。但本篇重点还是 OpenClaw Chrome CDP 这条链路模型通道只是配套。准备好这些之后下一节进入可复制的配置环节包括 Windows 上的 Chrome 启动命令、portproxy 转发规则、防火墙放行以及 OpenClaw 的 JSON 配置片段。3. 可复制配置Chrome 启动、portproxy 转发与 OpenClaw JSON这一节全是能直接复制粘贴的命令和配置按顺序做就行。先 Windows 端再 Ubuntu 端。3.1 Windows 上启动带 CDP 的 Chrome先建一个专用 profile 目录比如C:\chrome-openclaw-profile。然后以管理员身份打开 PowerShell启动 Chrometaskkill /F /IM chrome.exe Start-Process -FilePath C:\Program Files\Google\Chrome\Application\chrome.exe -ArgumentList --remote-debugging-port9222,--remote-debugging-address0.0.0.0,--user-data-dirC:\chrome-openclaw-profile,about:blank参数说明--remote-debugging-port9222开启 CDP 调试端口--remote-debugging-address0.0.0.0尝试让监听地址更宽但实际仍可能绑在 127.0.0.1所以后面还要 portproxy--user-data-dir指定专用 profile 目录about:blank给一个初始空白页方便测试/json/list。启动后先在 Windows 本机验证 Chrome 的 CDP 是否正常curl.exe http://127.0.0.1:9222/json/version curl.exe http://127.0.0.1:9222/json/list正常的话/json/version会返回一段 JSON里面有webSocketDebuggerUrl/json/list会返回标签页列表。如果这两个命令都不通先别往下走检查 Chrome 是不是真的起来了或者 9222 是不是被别的进程占了。3.2 检查 9222 是否被 portproxy 抢占这一步很多人会忽略但它是最大的坑之一。运行netstat -ano | findstr :9222看监听 9222 的 PID 对应的进程。如果显示的是svchost.exe再查服务名tasklist /svc /FI PID eq 那个PID如果服务名是iphlpsvc说明 9222 被 Windows 的端口代理层抢占了。再看netsh interface portproxy show all如果看到类似0.0.0.0 9222 127.0.0.1 9222的规则那就是历史遗留的 portproxy 规则在作怪。这种情况下Chrome 虽然带了--remote-debugging-port9222但真正监听 9222 的不是 Chrome而是 portproxy所以你访问/json/version会得到异常结果或者空回复。解决办法把旧的 9222 转发规则删掉让 Chrome 自己监听 9222然后另开一个 13333 做转发。netsh interface portproxy delete v4tov4 listenaddress0.0.0.0 listenport9222删完之后重启 Chrome再确认netstat -ano | findstr :9222对应的 PID 是chrome.exe。3.3 添加 13333 到 9222 的 portproxy 转发管理员 PowerShell 执行netsh interface portproxy add v4tov4 listenaddress0.0.0.0 listenport13333 connectaddress127.0.0.1 connectport9222查看确认netsh interface portproxy show all应该看到0.0.0.0 13333 127.0.0.1 92223.4 放行 Windows 防火墙先加一条规则New-NetFirewallRule -DisplayName Chrome CDP 13333 -Direction Inbound -Action Allow -Protocol TCP -LocalPort 13333 -Profile Private但实际网络配置文件不一定命中 Private所以后面要改成 AnySet-NetFirewallRule -DisplayName Chrome CDP 13333 -Profile Any这一步不做Ubuntu 那边访问 13333 会一直超时。3.5 OpenClaw 的 JSON 配置片段在 Ubuntu 的~/.openclaw/openclaw.json里浏览器和模型两块都要配。浏览器部分browser: { enabled: true, attachOnly: true, defaultProfile: remote, profiles: { remote: { cdpUrl: http://192.168.x.x:13333, attachOnly: true, color: #00AA00 }, openclaw: { cdpPort: 18800, color: #FF4500 } } }把192.168.x.x换成你 Windows 机器的局域网 IP。模型部分把 Base URL、Key、Model ID 三件套写全model: { baseUrl: https://taotoken.net/api, apiKey: 你的TaoToken Key, modelId: 你选的Model ID }如果你用的是 Claude Code 相关的接入配置方式类似文档在 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite 有说明。Coding Plan 适合长期编码和 Agent 场景入口在 https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding-planutm_campaignrewrite 。配置改完重启 OpenClawopenclaw gateway restart下一节验证整条链路是否通。4. 验证请求与成功结果从 curl 到 OpenClaw status配置写完不算完必须一步步验证。顺序是Windows 本机验证 Chrome CDPWindows 本机验证 13333 转发Ubuntu 验证 13333 可达最后 OpenClaw 验证 remote profile 连接成功。4.1 Windows 本机验证 13333 转发在 Windows 上执行curl http://192.168.x.x:13333/json/version curl http://192.168.x.x:13333/json/list返回正常 JSON说明 13333 到 9222 的转发成功且防火墙允许本机访问这个入口。如果这里就不通先回去检查 portproxy 规则和 Chrome 是否在监听 9222。4.2 Ubuntu 验证 13333 可达在 Ubuntu 终端执行curl http://192.168.x.x:13333/json/version curl http://192.168.x.x:13333/json/list这一步最初失败的概率很高原因通常是 Windows 防火墙规则只对 Private 生效而当前网络配置不是 Private。改成 Any 之后一般就恢复正常。如果还是不通用telnet 192.168.x.x 13333或者nc -zv 192.168.x.x 13333确认端口是否真的可达。4.3 OpenClaw 验证 remote profile重启 gateway 后依次执行openclaw browser --browser-profile remote status openclaw browser --browser-profile remote tabs openclaw browser --browser-profile remote snapshot预期结果status成功说明 OpenClaw 已连上远程 Chrometabs成功能看到about:blank标签页snapshot返回空白是正常的因为页面本身就是空白页不是失败。4.4 实际打开网页验证openclaw browser --browser-profile remote open https://www.baidu.com openclaw browser --browser-profile remote tabs openclaw browser --browser-profile remote snapshot --interactive openclaw browser --browser-profile remote screenshotopen打开网页tabs确认标签页存在snapshot --interactive获取可交互元素快照screenshot截图。这一套跑通说明整条链路从 Ubuntu OpenClaw 到 Windows Chrome 完全打通。如果模型调用也配了 TaoToken可以在 OpenClaw 执行任务时观察模型请求是否正常返回。模型对话页面 https://taotoken.net/models?utm_sourcetaotoken_aicg_blog_endutm_contentmodelsutm_campaignrewrite 可以单独测试 Key 和 Model ID 是否有效。验证通过后下一节把常见报错和排查方法列清楚方便你遇到问题时对照。5. 本篇常见错排查401、local proxy failed、reading choices、OAuth这一节按真实报错来遇到哪个查哪个。5.1 401 Unauthorized如果你在 OpenClaw 调用模型时看到 401基本是 TaoToken 的 Key 或 Base URL 配错了。检查三件套Base URL 是不是https://taotoken.net/apiKey 是不是完整复制没有多余空格Model ID 是不是在可用列表里。如果用的是 Claude Code 接入确认 OAuth 或者 API Key 的配置方式是否正确文档在 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite 。API Keys 管理页面在 https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi-keysutm_campaignrewrite 可以重新生成一个 Key 试试。5.2 local proxy failed这个报错通常出现在 OpenClaw 尝试连接浏览器或者模型 API 时。如果是浏览器侧检查cdpUrl是不是写成了http://127.0.0.1:13333在 Ubuntu 上必须写 Windows 的局域网 IP不能写 127.0.0.1。如果是模型侧检查 Base URL 是否可达可以用curl -I https://taotoken.net/api测试连通性。5.3 reading choices 相关报错这类报错一般是模型返回格式不符合预期或者 Model ID 填错了。确认你填的 Model ID 是 TaoToken 支持的不要自己拼。如果用的是 Coding Plan 场景入口在 https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding-planutm_campaignrewrite 按里面的说明配置。5.4 OAuth 相关报错如果你用 Claude Code 或者类似工具OAuth 流程可能因为回调地址或者网络问题失败。检查你的配置是否和文档一致必要时改用 API Key 方式。Claude Code 的接入说明在 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite 。5.5 端口 9222 被占用回到 Windowsnetstat -ano | findstr :9222看 PID 对应的是不是chrome.exe。如果是svchost.exe且服务是iphlpsvc说明有旧的 portproxy 规则。用netsh interface portproxy show all查看删掉占用 9222 的规则重启 Chrome。5.6 防火墙只放行 PrivateUbuntu 访问 13333 超时但 Windows 本机访问正常大概率是防火墙规则只对 Private 生效。执行Set-NetFirewallRule -DisplayName Chrome CDP 13333 -Profile Any改成 Any。5.7 about:blank 上 snapshot 为空这是正常现象不是失败。空白页本来就没有可交互元素换个真实网页再 snapshot 就有内容了。5.8 CC Switch / Cline MCP / Codex auth.json 场景如果你在这些工具里配置 TaoToken三件套同样要写全Base URL 用https://taotoken.net/apiKey 用控制台生成的Model ID 用实际支持的。Codex 的auth.json里字段名可能不同按文档填。Cline MCP 配置里注意不要直连生产库只做模型调用通道。排查完这些基本能覆盖大部分问题。下一节给出 CTA 和后续使用建议。6. 后续怎么用稳定调试环境与统一通道链路打通之后日常使用就简单了。Windows 上保留 13333 到 9222 的转发结构不要再把 9222 裸暴露出去。真正使用前先确保那个测试 Chrome 实例开着profile 目录C:\chrome-openclaw-profile里的登录态会一直保留。常用命令就那几条openclaw browser --browser-profile remote open https://example.com openclaw browser --browser-profile remote tabs openclaw browser --browser-profile remote snapshot --interactive openclaw browser --browser-profile remote screenshot如果以后换了 Windows IP记得同步修改 OpenClaw 里的cdpUrl。模型通道那边TaoToken 的 Key 和 Model ID 如果换了也同步更新配置。模型对话测试入口在 https://taotoken.net/models?utm_sourcetaotoken_aicg_blog_endutm_contentmodelsutm_campaignrewrite API Keys 管理在 https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi-keysutm_campaignrewrite 接入文档在 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite 。这套环境的价值在于可复现。你不需要每次重新登录网站不需要反复调端口Chrome 实例和 OpenClaw 配置都固定下来。后续可以在这个基础上练完整的自动化流程open、snapshot --interactive、click、type、screenshot逐步把常用操作脚本化。最后提醒一句portproxy 规则和防火墙规则是 Windows 层面的重启机器后一般还在但如果系统更新或者网络配置变了回来检查一下netsh interface portproxy show all和防火墙规则是否还在。养成这个习惯调试环境就能长期稳定。
函数用法讲解)
