1. 为什么 Ubuntu 上的 OpenClaw 连不上 Windows 的 Chrome
先说清楚这套链路到底在解决什么问题。你在 Ubuntu 上跑 OpenClaw，想让它去操作另一台 Windows 机器上的 Chrome 浏览器，做自动化点击、截图、抓取页面快照这类事情。听起来简单，但真动手就会发现：OpenClaw 默认的浏览器配置是给「本机浏览器」用的，跨机器根本连不上。
核心矛盾在于 Chrome 的调试协议 CDP（Chrome DevTools Protocol）默认只监听 127.0.0.1，也就是只有本机能访问。你在 Windows 上开了--remote-debugging-port=9222，Ubuntu 那边curl http://windows-ip:9222/json/version大概率是超时或者拒绝连接。这不是 OpenClaw 的问题，也不是 Chrome 的问题，是网络层和监听地址的问题。
我试过直接在 OpenClaw 里填cdpUrl: "http://192.168.x.x:9222"，结果一直报连接失败。后来才搞明白，Chrome 那个--remote-debugging-address=0.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或者profile="user"。那种模式适合同一台机器上 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_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite&utm_content= ，API 入口是 https://taotoken.net/api 。你注册后在控制台生成 Key，然后把这个 Key 填到 OpenClaw 的模型配置里就行。
具体要准备的东西：
第一，一个 TaoToken 的 API Key。去控制台 https://taotoken.net/console?utm_source=taotoken_aicg_blog_end&utm_content=console&utm_campaign=rewrite 创建，复制出来备用。这个 Key 就是你所有模型调用的通行证。
第二，确认你要用的模型 ID。TaoToken 支持多种模型，你在模型对话页面 https://taotoken.net/models?utm_source=taotoken_aicg_blog_end&utm_content=models&utm_campaign=rewrite 能看到可用列表。记下你要用的那个 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_source=taotoken_aicg_blog_end&utm_content=doc&utm_campaign=rewrite 。但本篇重点还是 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，启动 Chrome：
taskkill /F /IM chrome.exe Start-Process -FilePath "C:\Program Files\Google\Chrome\Application\chrome.exe" -ArgumentList "--remote-debugging-port=9222","--remote-debugging-address=0.0.0.0","--user-data-dir=C:\chrome-openclaw-profile","about:blank"参数说明：--remote-debugging-port=9222开启 CDP 调试端口；--remote-debugging-address=0.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-port=9222，但真正监听 9222 的不是 Chrome，而是 portproxy，所以你访问/json/version会得到异常结果或者空回复。
解决办法：把旧的 9222 转发规则删掉，让 Chrome 自己监听 9222，然后另开一个 13333 做转发。
netsh interface portproxy delete v4tov4 listenaddress=0.0.0.0 listenport=9222删完之后重启 Chrome，再确认netstat -ano | findstr :9222对应的 PID 是chrome.exe。
3.3 添加 13333 到 9222 的 portproxy 转发
管理员 PowerShell 执行：
netsh interface portproxy add v4tov4 listenaddress=0.0.0.0 listenport=13333 connectaddress=127.0.0.1 connectport=9222查看确认：
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，所以后面要改成 Any：
Set-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_source=taotoken_aicg_blog_end&utm_content=doc&utm_campaign=rewrite 有说明。Coding Plan 适合长期编码和 Agent 场景，入口在 https://taotoken.net/coding-plan?utm_source=taotoken_aicg_blog_end&utm_content=coding-plan&utm_campaign=rewrite 。
配置改完，重启 OpenClaw：
openclaw gateway restart下一节验证整条链路是否通。
4. 验证请求与成功结果：从 curl 到 OpenClaw status
配置写完不算完，必须一步步验证。顺序是：Windows 本机验证 Chrome CDP，Windows 本机验证 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 已连上远程 Chrome；tabs成功，能看到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_source=taotoken_aicg_blog_end&utm_content=models&utm_campaign=rewrite 可以单独测试 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/api，Key 是不是完整复制没有多余空格，Model ID 是不是在可用列表里。如果用的是 Claude Code 接入，确认 OAuth 或者 API Key 的配置方式是否正确，文档在 https://taotoken.net/doc?utm_source=taotoken_aicg_blog_end&utm_content=doc&utm_campaign=rewrite 。API Keys 管理页面在 https://taotoken.net/api-keys?utm_source=taotoken_aicg_blog_end&utm_content=api-keys&utm_campaign=rewrite ，可以重新生成一个 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_source=taotoken_aicg_blog_end&utm_content=coding-plan&utm_campaign=rewrite ，按里面的说明配置。
5.4 OAuth 相关报错
如果你用 Claude Code 或者类似工具，OAuth 流程可能因为回调地址或者网络问题失败。检查你的配置是否和文档一致，必要时改用 API Key 方式。Claude Code 的接入说明在 https://taotoken.net/doc?utm_source=taotoken_aicg_blog_end&utm_content=doc&utm_campaign=rewrite 。
5.5 端口 9222 被占用
回到 Windows，netstat -ano | findstr :9222，看 PID 对应的是不是chrome.exe。如果是svchost.exe且服务是iphlpsvc，说明有旧的 portproxy 规则。用netsh interface portproxy show all查看，删掉占用 9222 的规则，重启 Chrome。
5.6 防火墙只放行 Private
Ubuntu 访问 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/api，Key 用控制台生成的，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_source=taotoken_aicg_blog_end&utm_content=models&utm_campaign=rewrite ，API Keys 管理在 https://taotoken.net/api-keys?utm_source=taotoken_aicg_blog_end&utm_content=api-keys&utm_campaign=rewrite ，接入文档在 https://taotoken.net/doc?utm_source=taotoken_aicg_blog_end&utm_content=doc&utm_campaign=rewrite 。
这套环境的价值在于可复现。你不需要每次重新登录网站，不需要反复调端口，Chrome 实例和 OpenClaw 配置都固定下来。后续可以在这个基础上练完整的自动化流程：open、snapshot --interactive、click、type、screenshot，逐步把常用操作脚本化。
最后提醒一句：portproxy 规则和防火墙规则是 Windows 层面的，重启机器后一般还在，但如果系统更新或者网络配置变了，回来检查一下netsh interface portproxy show all和防火墙规则是否还在。养成这个习惯，调试环境就能长期稳定。
