企业官网建设流程全解析

1. Windows 部署 open claw 后浏览器打不开，先别急着重装

open claw 是一套跑在容器里的智能体工作台，自带 Canvas 画布、任务编排和模型调用面板，适合想在本地折腾 Agent 流程、又不想把数据丢到公网的人。Windows 上部署它，通常走 Docker Desktop + WSL2 这条路，容器起来了、日志也正常，但浏览器输入http://127.0.0.1:18788/__openclaw__/canvas/就是转圈或者直接「无法访问此网站」——这是搜索「window open claw 浏览器无法访问」时出现频率最高的一类问题。

我上周也踩了同一个坑：容器重建后端口转发失效，Web 面板彻底打不开，日志里却看不出任何报错。后来把网络、端口、鉴权三条链路逐段拆开测，才发现问题根本不在 open claw 本身，而是 Windows 到 WSL2 的端口映射断了，加上模型通道的 Key 没配对，两个故障叠在一起，表现就成了「浏览器无法访问」。

这篇就按我实际排查的顺序来写：先讲清楚 open claw 在 Windows 上的网络结构，再给出 TaoToken 统一 Key 通道的配置文件骨架（settings.json和config.toml），然后是可直接复制的端口转发与连通性验证命令，最后把三类常见故障——网络层、端口层、鉴权层——的排查动作列全。你跟着走一遍，基本能从「打不开」走到「画布正常加载」。

需要提前说明的是，open claw 的 Web 面板和模型调用是两条独立的链路：面板打不开属于网络/端口问题，面板能开但对话报 401/403 属于鉴权问题。很多人把这两类混在一起查，越查越乱。下面会分开处理。

2. TaoToken 统一 Key 通道：open claw 的模型接入前置

open claw 本身不绑定某一家模型服务，它通过 OpenAI 兼容协议去调用后端。也就是说，你只要给它一个base_url和一个api_key，它就能把对话、嵌入、工具调用这些请求发出去。TaoToken 在这里扮演的角色就是「统一 Key 通道」：一个 Key 覆盖多家模型，接口地址统一，省得你在 open claw 里为每个模型单独配一套环境变量。

对 open claw 来说，需要填的核心就三项：

这里有个容易搞混的点：base_url填的是 API 根地址，不是官网首页。open claw 内部会在这个地址后面拼/v1/chat/completions之类的路径，所以你填https://taotoken.net/api就够了，不要自己再加/v1，否则会拼成/api/v1/v1/...直接 404。

Key 的获取路径是：登录后进控制台，在 API Keys 页面新建一个 Key，复制出来。这个 Key 只在创建时完整显示一次，记得先存到密码管理器里。如果你还没配好通道，可以先到模型对话页面确认账号状态正常，再去生成 Key。

注意：open claw 的 Web 面板访问和模型 Key 是两回事。面板打不开时，不要反复重新生成 Key，那解决不了端口问题；反过来，面板能开但对话报错时，也不要反复重启容器，那解决不了鉴权问题。

3. 可复制配置：settings.json 与 config.toml 骨架

open claw 的配置分两处：容器内的settings.json管运行时行为，宿主机的config.toml管启动参数和挂载。两个文件都要填对，缺一个都可能出现「容器起来了但面板空白」。

3.1 settings.json 骨架

这个文件在容器里的路径是/home/node/.openclaw/settings.json，对应你挂载出来的~/openclaw/data/settings.json。直接编辑宿主机上的那份就行，改完重启容器生效。

{ "server": { "host": "0.0.0.0", "port": 18789, "canvasPort": 18788 }, "model": { "provider": "openai-compatible", "baseUrl": "https://taotoken.net/api", "apiKey": "sk-你的Key粘贴在这里", "defaultModel": "你的默认模型名", "timeoutMs": 60000 }, "auth": { "enabled": true, "token": "面板访问口令，自己设一个" }, "logging": { "level": "info" } }

几个字段的坑点：host必须是0.0.0.0，如果写成127.0.0.1，容器外部永远访问不到；canvasPort和port不要填成同一个值，open claw 内部用两个端口分别处理 API 和画布；apiKey不要带引号外的空格，复制时很容易多一个换行。

3.2 config.toml 骨架

宿主机上的config.toml一般放在~/openclaw/config.toml，控制容器的启动映射。如果你用docker run直接起，可以跳过这个文件；如果用 compose 或脚本管理，建议把端口和挂载写进去。

[container] name = "openclaw" image = "ghcr.io/openclaw/openclaw:latest" restart = "always" user = "root" [ports] api = "0.0.0.0:18789:18789" canvas = "0.0.0.0:18788:18788" extra = ["0.0.0.0:18791:18791", "0.0.0.0:18792:18792"] [volumes] data = "~/openclaw/data:/home/node/.openclaw" [env] OPENCLAW_LOG_LEVEL = "info"

ports段里的0.0.0.0:前缀不能省，省了默认只绑127.0.0.1，WSL2 里的容器就暴露不到 Windows 主机。volumes的路径用~在部分 Windows 终端里不展开，建议写成绝对路径，比如/home/你的用户名/openclaw/data。

3.3 重建容器并确认启动

配置改完后，删掉旧容器重建，让新配置生效：

docker rm -f openclaw docker run -d \ --name openclaw \ --restart=always \ -p 0.0.0.0:18788:18788 \ -p 0.0.0.0:18789:18789 \ -p 0.0.0.0:18791:18791 \ -v ~/openclaw/data:/home/node/.openclaw \ --user root \ ghcr.io/openclaw/openclaw:latest

等 30 秒，看日志确认没有崩溃循环：

docker logs openclaw --tail 30

正常的话你会看到类似canvas server listening on 0.0.0.0:18788和api server listening on 0.0.0.0:18789两行。如果只看到一行，说明另一个端口被占用或配置没读到，回到settings.json检查端口字段。

4. 分步验证：从容器内到浏览器打通链路

配置填对只是第一步，真正决定浏览器能不能打开的是「Windows → WSL2 → 容器」这条转发链。下面按从内到外的顺序验证，哪一步断了就修哪一步。

4.1 容器内自测

先进容器，确认服务本身是活的：

docker exec -it openclaw /bin/sh curl -I http://127.0.0.1:18788/__openclaw__/canvas/

返回HTTP/1.1 200 OK或302都算正常。如果这里就失败，说明 open claw 进程没起来，跟 Windows 网络无关，去看docker logs里的报错。

4.2 WSL2 内自测

退出容器，在 WSL2 终端里测：

curl -I http://127.0.0.1:18788/__openclaw__/canvas/

这一步通，说明 Docker 的端口映射没问题。如果不通，检查docker ps里端口那列是不是0.0.0.0:18788->18788/tcp，如果是127.0.0.1:18788->...，说明启动命令里少了0.0.0.0前缀。

4.3 Windows 侧端口转发检查

打开管理员 PowerShell，先看现有转发规则：

netsh interface portproxy show all

正常应该能看到 18788 指向 WSL2 的 IP。如果没有，手动补一条：

netsh interface portproxy add v4tov4 listenport=18788 listenaddress=0.0.0.0 connectport=18788 connectaddress=172.18.196.44

这里的172.18.196.44要换成你 WSL2 的实际 IP，用wsl hostname -I查。注意 WSL2 的 IP 每次重启可能变，所以更稳的做法是用localhost转发，或者写个脚本每次启动时刷新规则。

4.4 连通性测试

Test-NetConnection 172.18.196.44 -Port 18788

看到TcpTestSucceeded : True就说明端口通了。这时候浏览器访问http://172.18.196.44:18788/__openclaw__/canvas/，应该能加载出画布。如果还是打不开，先临时关掉防火墙验证：

netsh advfirewall set allprofiles state off

刷新浏览器，能开就说明是防火墙拦截，再针对性放行 18788 端口，而不是一直关着防火墙。

4.5 模型通道验证

面板能开后，进设置页填 TaoToken 的 Key，或者直接在settings.json里配好。验证模型通不通，用一条 curl：

curl https://taotoken.net/api/v1/chat/completions \ -H "Authorization: Bearer sk-你的Key" \ -H "Content-Type: application/json" \ -d '{"model":"你的模型名","messages":[{"role":"user","content":"ping"}]}'

返回带choices的 JSON 就说明鉴权通过。如果返回 401，检查 Key 有没有多余空格；返回 404，检查base_url是不是多写了/v1。

5. 本篇常见错排查：网络、端口、鉴权三类故障

把上面流程走一遍后，剩下的问题基本能归到三类。下面按现象反查原因，方便你对号入座。

第一类：浏览器提示「无法访问此网站」，curl 容器内正常。这是最典型的端口转发缺失。WSL2 的 IP 在重启后会变，旧的 portproxy 规则还指向老 IP，自然不通。解决动作：wsl hostname -I拿新 IP，删掉旧规则netsh interface portproxy delete v4tov4 listenport=18788，再重新 add。想一劳永逸，可以写个开机脚本自动刷新。

第二类：端口通了但页面空白或 502。通常是settings.json里host写成了127.0.0.1，或者canvasPort和port冲突。检查容器日志有没有EADDRINUSE，有就是端口占用，换一个端口重新映射。

第三类：面板能开，但对话报 401/403。这是鉴权层问题，跟网络无关。先确认 Key 没过期，再确认baseUrl没写错。open claw 有些版本会把 Key 缓存在内存里，改完settings.json必须重启容器才生效，光刷新页面没用。

还有一个隐蔽的坑：Windows 上同时装了 Docker Desktop 和 WSL2 自带的 Docker，两个环境的端口映射会打架。确认你docker ps看到的是同一个 daemon，别在 WSL2 里起了容器，却在 Docker Desktop 的上下文里查端口。

6. 配好之后：把 Key 通道和面板访问固定下来

走到这里，浏览器应该能正常打开 open claw 的画布了。剩下要做的两件事：一是把 WSL2 的端口转发规则做成开机自启，避免每次重启后重新配；二是把 TaoToken 的 Key 和base_url固化到settings.json，别每次手动填。

如果你打算长期跑 Agent 任务、频繁调用模型，可以到 Coding Plan 页面看看额度方案，比按次调用更划算。Key 的管理和轮换在 API Keys 页面操作，接入细节和参数说明在接入文档里有完整列表。面板本身的功能验证，可以直接在模型对话里发一条消息，确认端到端链路是通的。

最后提醒一句：settings.json里存了明文 Key，挂载目录别放到共享盘或者会同步到公网的位置。本地折腾没问题，但养成习惯总没错。