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]段和systemdtrue。如果没有说明 systemd 没开后面所有systemctl命令都会报System has not been booted with systemd。第三条如果显示inactive或active都正常inactive说明服务已注册但没启动active说明正在跑。如果第二条没有systemdtrue先补上。编辑/etc/wsl.conf# 在 WSL 内执行 sudo tee /etc/wsl.conf /dev/null EOF [boot] systemdtrue [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直接 enablesudo systemctl enable openclaw sudo systemctl start openclaw systemctl status openclaw --no-pager如果是用户级 unit则用--usersystemctl --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 通道统一指向 TaoTokenKey 用你在控制台创建的 KeyBase 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_KEYsk-你的TaoTokenKey然后 settings 里用apiKey: ${TAOTOKEN_API_KEY}引用。改完source ~/.bashrc并重启服务。5. 常见报错排查401、local proxy failed、reading choices、OAuth自启配好后最常见的不是进程问题而是鉴权和请求格式问题。下面按真实报错逐条排查。401 Unauthorized。这是 Key 问题。先确认 settings 里的apiKey和你在 TaoToken 控制台创建的一致注意不要有多余空格或换行。用 curl 直接测 Keycurl -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字段是你账号下可用的 IDmessages是数组且每条有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.1WSL 内可访问但 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里 exportsettings 用${TAOTOKEN_API_KEY}引用。这样换 Key 只改一处不用动配置文件。分环境可以用settings.dev.json和settings.prod.json启动时用--settings指定。如果你后面要做长期编码或 Agent 类任务建议把接入方式固定下来Base URL 用https://taotoken.net/apiKey 从控制台创建Model ID 按任务选。需要新建 Key 或查看用量去控制台页面操作即可。接入细节和参数说明可以对照接入文档里面有各语言的示例。创建和管理 Keyhttps://taotoken.net/console/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi_keysutm_campaignrewrite接入文档https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite模型对话快速验证https://taotoken.net/chat?utm_sourcetaotoken_aicg_blog_endutm_contentmodel_chatutm_campaignrewrite长期编码与 Agent 场景https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding_planutm_campaignrewrite最后留一个实用习惯每次改完 settings先systemctl restart openclaw再 curl 一次/health和一次对话请求两个都过再关机。这样下次开机自启后你面对的是一个确定可用的服务而不是一个“进程活着但请求全挂”的假象。