1. 为什么 WSL2 里的 OpenClaw 重启就“失联”
很多人第一次在 Windows 11 上装 OpenClaw，流程大概是这样的：装好 WSL2、装好 Ubuntu、把 OpenClaw 跑起来，浏览器打开http://localhost:端口号一切正常，心里美滋滋。结果第二天开机，浏览器直接打不开，进 WSL 一看，systemctl status openclaw显示inactive (dead)，服务根本没起来。这就是典型的“手动能跑、开机不自启”问题。
OpenClaw 本身是一个常驻型服务，它需要有人把它拉起来，并且保证 WSL 这个“容器”在开机后也处于运行状态。Windows 和 WSL2 之间有一层边界：Windows 开机不会自动帮你启动某个 WSL 发行版，WSL 发行版不启动，里面的 systemd 就不会跑，systemd 不跑，OpenClaw 这个 unit 自然也不会被拉起。所以“开机自启”这件事，本质上是两段链路要同时打通：第一段是 Windows 侧把 WSL 拉起来，第二段是 WSL 内部把 OpenClaw 服务拉起来。
我试过只做其中一段，结果就是各种半吊子状态：只配 systemd，开机后 WSL 没启动，服务等于没配；只配 Windows 任务计划拉起 WSL，但 WSL 里 systemd 没开，OpenClaw 还是不会自动跑。所以这篇教程会把两条路径都讲清楚，并且告诉你什么场景选哪条。
另外还有一个容易被忽略的点：OpenClaw 的settings里如果写的是某个临时 Key 或者本地 mock 地址，开机自启后第一次请求就会鉴权失败。所以自启和鉴权要一起验证，不能只看进程在不在。这篇会顺带把settings指向 TaoToken 统一 Key/API 通道的写法给出来，让自启之后服务是真的可用，而不是“进程活着但请求全挂”。
适合谁看：零基础、刚接触 WSL2、想让 OpenClaw 开机自动跑起来、又不想每次手动敲命令的人。下面所有命令都可以直接复制，路径和参数我会写全。
2. 前置检查：WSL2、systemd 与 OpenClaw 服务状态确认
在动手配自启之前，先把当前环境摸清楚。很多人卡住不是因为自启配错，而是前置条件根本没满足。打开 PowerShell（普通用户即可，不需要管理员），依次执行下面三条命令。
# 1. 查看 WSL 版本，确认是 2 wsl -l -v # 2. 查看 systemd 配置 wsl -d Ubuntu -- cat /etc/wsl.conf # 3. 查看 OpenClaw 服务状态（WSL 正在运行时） wsl -d Ubuntu -- systemctl status openclaw --no-pager第一条预期输出里，Ubuntu 那一行的 VERSION 应该是2。如果是1，需要先升级：wsl --set-version Ubuntu 2。第二条预期能看到[boot]段和systemd=true。如果没有，说明 systemd 没开，后面所有systemctl命令都会报System has not been booted with systemd。第三条如果显示inactive或active都正常，inactive说明服务已注册但没启动，active说明正在跑。
如果第二条没有systemd=true，先补上。编辑/etc/wsl.conf：
# 在 WSL 内执行 sudo tee /etc/wsl.conf > /dev/null <<'EOF' [boot] systemd=true [user] default=你的用户名 EOF写完退出 WSL，在 PowerShell 执行wsl --shutdown，等 5 秒再wsl -d Ubuntu进入，重新cat /etc/wsl.conf确认生效。这一步是后面 systemd 自启路径的地基，不能跳过。
还要确认 OpenClaw 已经注册为服务。如果你之前执行过openclaw onboard --install-daemon，那 unit 文件一般已经在/etc/systemd/system/openclaw.service或用户级~/.config/systemd/user/openclaw.service。用下面命令确认：
# 系统级 unit ls -l /etc/systemd/system/openclaw.service # 用户级 unit ls -l ~/.config/systemd/user/openclaw.service如果两个都不存在，说明服务没注册，需要先跑一次openclaw onboard --install-daemon。另外 linger 也要开，否则用户级服务在没人登录时不会启动：
sudo loginctl enable-linger "$(whoami)"这一步做完，前置条件才算齐。下面进入两条自启路径的取舍。
3. 两条自启路径取舍：systemd unit 与 Windows 任务计划配置
自启有两条主流路径，各有适用场景，不是谁替代谁。
第一条是WSL 内部 systemd 自启。它的前提是 WSL 发行版已经被启动。也就是说，只要 WSL 在跑，systemd 就会按enable状态把 OpenClaw 拉起来。优点是配置干净、和 Linux 服务管理习惯一致、日志用journalctl就能看。缺点是它管不了“WSL 本身要不要开机启动”这件事。
第二条是Windows 任务计划拉起 WSL。它解决的是“开机后 WSL 根本没启动”的问题。通过任务计划在登录时执行wsl.exe -d Ubuntu，把发行版唤醒，剩下的交给 systemd。优点是补上了 Windows 侧那一环，适合希望开机即用、不想手动开终端的场景。缺点是任务计划配置项多，容易配错触发条件。
我的建议是：两条一起用。systemd 负责服务级自启，任务计划负责把 WSL 唤醒。只配一条都会有缺口。下面给出两段可复制的配置。
先看 systemd 侧。如果你用的是系统级 unit，直接 enable：
sudo systemctl enable openclaw sudo systemctl start openclaw systemctl status openclaw --no-pager如果是用户级 unit，则用--user：
systemctl --user enable openclaw systemctl --user start openclaw systemctl --user status openclaw --no-pager再看 Windows 任务计划。用管理员 PowerShell 执行，创建一个登录时触发的任务：
$action = New-ScheduledTaskAction -Execute "wsl.exe" -Argument "-d Ubuntu --exec /bin/true" $trigger = New-ScheduledTaskTrigger -AtLogOn $settings = New-ScheduledTaskSettingsSet -AllowStartIfOnBatteries -DontStopIfGoingOnBatteries Register-ScheduledTask -TaskName "OpenClaw WSL Boot" -Action $action -Trigger $trigger -Settings $settings -RunLevel Limited这里--exec /bin/true只是把发行版唤醒，真正的服务启动交给 systemd。任务计划触发后 WSL 进入运行态，systemd 随即按 enable 状态拉起 OpenClaw。
接下来是settings指向 TaoToken 的部分。OpenClaw 的配置文件通常在~/.openclaw/settings.json或项目目录下的settings.json。把 API 通道统一指向 TaoToken，Key 用你在控制台创建的 Key，Base URL 用https://taotoken.net/api。可复制片段如下：
{ "api": { "baseUrl": "https://taotoken.net/api", "apiKey": "sk-你的TaoTokenKey", "model": "claude-sonnet-4-20250514" }, "server": { "port": 3000, "host": "0.0.0.0" } }注意baseUrl不要带 UTM 参数，API 地址就是https://taotoken.net/api。Key 建议放在环境变量里而不是硬编码，但零基础阶段先写进配置能跑通，后面再改成env引用。模型 ID 按你实际可用的填，这里只是示例。
如果你用的是 TOML 风格配置（部分版本支持），等价写法：
[api] base_url = "https://taotoken.net/api" api_key = "sk-你的TaoTokenKey" model = "claude-sonnet-4-20250514" [server] port = 3000 host = "0.0.0.0"配置改完，重启服务让 settings 生效：
sudo systemctl restart openclaw到这里，两条自启路径和 settings 指向都配好了。下一节做重启验证。
4. 重启验证：确认自启与鉴权同时生效
配置写完不算数，必须重启验证。验证分两层：进程层和请求层。进程层看服务有没有自动起来，请求层看鉴权有没有通过。
先做一次完整重启。在 PowerShell 执行：
wsl --shutdown Start-Sleep -Seconds 5 wsl -d Ubuntu -- systemctl status openclaw --no-pager预期输出里Active:应该是active (running)。如果还是inactive，说明 systemd enable 没生效或 unit 路径不对，回到第 3 节检查。
接着验证端口监听：
wsl -d Ubuntu -- sudo netstat -tlnp | grep -E ":(3000|5000|8080)" | grep -i node能看到0.0.0.0:3000或:::3000这类监听就对了。端口号以你 settings 里的server.port为准。
然后做请求层验证。在 WSL 内直接 curl 本地服务：
wsl -d Ubuntu -- curl -s http://localhost:3000/health如果返回{"status":"ok"}之类，说明服务本身活着。但真正要验证的是鉴权链路，也就是 OpenClaw 通过 TaoToken 发出去的请求能不能成功。用一个最小对话请求测试：
curl -s https://taotoken.net/api/v1/chat/completions \ -H "Authorization: Bearer sk-你的TaoTokenKey" \ -H "Content-Type: application/json" \ -d '{ "model": "claude-sonnet-4-20250514", "messages": [{"role": "user", "content": "ping"}], "max_tokens": 16 }'预期返回里能看到choices数组和内容。如果返回 401，说明 Key 不对或没带上；如果返回local proxy failed之类，说明 Base URL 写错或网络出口有问题。这一步过了，才说明“自启 + 鉴权”整条链路是通的。
最后做一次开机级验证：重启 Windows，登录后不要手动开终端，等 30 秒，直接在浏览器访问http://localhost:3000。能打开就说明任务计划和 systemd 都生效了。如果打不开，先wsl -l -v看 Ubuntu 是不是 Running，再看systemctl status openclaw。
验证通过后，建议把 Key 从明文配置挪到环境变量，减少泄露风险。在~/.bashrc里加：
export TAOTOKEN_API_KEY="sk-你的TaoTokenKey"然后 settings 里用"apiKey": "${TAOTOKEN_API_KEY}"引用。改完source ~/.bashrc并重启服务。
5. 常见报错排查：401、local proxy failed、reading choices、OAuth
自启配好后，最常见的不是进程问题，而是鉴权和请求格式问题。下面按真实报错逐条排查。
401 Unauthorized。这是 Key 问题。先确认 settings 里的apiKey和你在 TaoToken 控制台创建的一致，注意不要有多余空格或换行。用 curl 直接测 Key：
curl -s -o /dev/null -w "%{http_code}" https://taotoken.net/api/v1/models \ -H "Authorization: Bearer sk-你的TaoTokenKey"返回 200 说明 Key 有效，返回 401 说明 Key 本身有问题，去控制台重新生成。如果 curl 通了但 OpenClaw 报 401，说明 settings 没被正确加载，检查配置文件路径和 JSON 语法。
local proxy failed。这个报错通常出现在 Base URL 写错或本地代理配置冲突时。确认baseUrl是https://taotoken.net/api，不要写成带路径的https://taotoken.net/api/v1再加/chat/completions导致重复。另外检查 WSL 内是否有残留的HTTP_PROXY环境变量：
env | grep -i proxy如果有，unset HTTP_PROXY HTTPS_PROXY后再重启服务。
reading choices 报错。典型是响应结构不符合预期，常见于模型 ID 写错或请求体格式不对。确认model字段是你账号下可用的 ID，messages是数组且每条有role和content。用 curl 复现一次，看返回体里有没有choices。如果返回的是错误对象，先解决错误对象里的 message。
OAuth 相关报错。如果你用的是需要 OAuth 的客户端（比如某些 CLI 工具），要确认 token 没过期。OAuth 和 API Key 是两套东西，OpenClaw 的 settings 里如果混用了 OAuth token 当 apiKey，会报鉴权失败。统一用 TaoToken 的 API Key 即可。
服务 active 但浏览器打不开。检查server.host是不是0.0.0.0，如果是127.0.0.1，WSL 内可访问但 Windows 侧可能映射不到。改成0.0.0.0后重启。另外 Windows 防火墙偶尔会拦，临时关掉测试一下。
开机后 WSL 没启动。检查任务计划是否真的触发了：Get-ScheduledTaskInfo -TaskName "OpenClaw WSL Boot"看LastRunTime。如果没跑，检查触发条件是不是AtLogOn，以及任务是否被禁用。
排查顺序建议：先 curl 测 Key，再 curl 测服务，再看 journalctl 日志：
wsl -d Ubuntu -- journalctl -u openclaw --no-pager -n 50日志里通常直接写着失败原因，比猜快得多。
6. 把 Key 管好：接入文档与长期编码的下一步
自启跑通之后，真正要长期维护的是 Key 和配置的整洁度。明文 Key 写在 settings 里能跑，但不适合长期放着。建议做三件事：Key 放环境变量、配置分环境、定期轮换。
环境变量方式前面提过，在~/.bashrc里 export，settings 用${TAOTOKEN_API_KEY}引用。这样换 Key 只改一处，不用动配置文件。分环境可以用settings.dev.json和settings.prod.json，启动时用--settings指定。
如果你后面要做长期编码或 Agent 类任务，建议把接入方式固定下来：Base URL 用https://taotoken.net/api，Key 从控制台创建，Model ID 按任务选。需要新建 Key 或查看用量，去控制台页面操作即可。接入细节和参数说明可以对照接入文档，里面有各语言的示例。
- 创建和管理 Key：https://taotoken.net/console/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
- 模型对话快速验证：https://taotoken.net/chat?utm_source=taotoken_aicg_blog_end&utm_content=model_chat&utm_campaign=rewrite
- 长期编码与 Agent 场景：https://taotoken.net/coding-plan?utm_source=taotoken_aicg_blog_end&utm_content=coding_plan&utm_campaign=rewrite
最后留一个实用习惯：每次改完 settings，先systemctl restart openclaw，再 curl 一次/health和一次对话请求，两个都过再关机。这样下次开机自启后，你面对的是一个确定可用的服务，而不是一个“进程活着但请求全挂”的假象。
