先把结论放前面这个报错我排查了一整天才彻底解决原因比想象中隐蔽但解决思路其实就那么几条。如果你正在给 OpenClaw 换运行目录、搬数据盘或者刚装完 Windows Companion 准备连 WSL 里的网关突然看到gateway closed (1006 abnormal closure (no close frame)别慌这篇文章就是给你写的。我会从网关工作原理讲起再带你一步步排查配置、环境、端口和权限最后给出一套可以直接抄作业的修复流程。无论你是刚接触 OpenClaw 的小白还是已经被这个 1006 折磨到想砸键盘的老手按这个顺序查大概率能在半小时内恢复连接。1. 先搞懂 OpenClaw 的网关在整条链路里是什么角色1.1 OpenClaw 的部署形态WSL 里跑服务Windows 这边做桥接OpenClaw 是那种典型的控制台在云端、执行在本地的 AI 助理框架它由多个进程配合工作。最常见的一套跑法是WSL2 的 Ubuntu 里跑核心服务我们常说的 gatewayWindows 这边跑一个 Companion 进程做桥接把消息平台的推送转给 WSL 里的网关处理。网关gateway这个词本身很形象它就像大厦的总机接线员——所有外部消息要进来必须先打到总机再由总机转给对应的分机工具调用、技能执行、知识库查询。如果总机断了外部就完全联系不上里面的分机表现就是消息发不出去、工具调用无响应而日志里往往就躺着gateway closed (1006 abnormal closure (no close frame)。修改运行目录之所以会牵动网关是因为 OpenClaw 的服务启动时需要依赖配置文件去定位数据目录、日志目录、临时文件目录、会话存储等。一旦你改了目录但没同步更新配置或者新目录的权限、路径格式有问题网关进程会在启动早期“带病运行”随后在某次读取文件或建立 WebSocket 连接时直接崩掉表现就是 1006——异常关闭没有任何 close frame。1.2 1006 到底是什么意思连接被“硬掐断”而非“礼貌告别”WebSocket 协议里连接关闭分两种正常关闭会发送一个 close frame关闭帧里面带着状态码和原因比如 1000 表示 normal closure。而 1006 是极其特殊的一个码——它不是从远端收到的而是本地检测到连接异常中断后由 WebSocket 实现自己生成的状态码意思是“我根本没收到对方的 close frame连接就断了”。这就好比两个人在打电话正常挂机会听到“嘟”一声然后通话结束1006 就是电话打着打着突然信号中断你完全不知道对面发生了什么。所以排查 1006 时我们不能指望日志里给出原因码必须自己去检查底层的连接链路、进程状态和配置正确性。结合我遇到的情况和社区里其他人的反馈1006 出现的原因通常集中在以下几类网关进程启动后因为配置错误、权限错误或崩溃而退出导致连接被动断掉修改运行目录后配置里指向的路径已失效服务启动到一半读取不到关键文件直接退出WSL 环境异常比如 WSL 没正常启动、版本不对、Node 环境缺失服务根本没起来端口被占用或被防火墙拦截握手过程中连接被中途切断2. 从报错现场反向排查三个关键检查点2.1 修改运行目录后第一件事是确认 WSL 环境还健康很多人改目录时从来不碰 WSL觉得环境不会有事但实际恰恰相反。如果你把 OpenClaw 的运行目录从 WSL 原生的~\openclaw迁到了/mnt/c/...挂载的 Windows 盘符文件系统类型和权限模型会完全不同。WSL 里跨文件系统操作有很多坑最常见的是权限位失效、元数据丢失甚至某些操作直接报Operation not permitted。先按这个顺序检查打开 PowerShell运行wsl --status看输出里 WSL 版本是否显示 2。如果显示的是 WSL 1那 1006 几乎可以提前下结论——WSL1 对 WebSocket 和网络转发的支持不完整很多场景下连接会不稳定加上你改了目录服务更容易启动失败。如果状态正常再运行wsl -l -v确认 Ubuntu 发行版处于 Running 状态。如果显示 Stopped用wsl --shutdown全部停掉再重新进入。注意wsl --shutdown会关闭所有发行版重启后等个十来秒再操作别急着启动服务。进到 WSL 里之后检查 Node.js 版本。OpenClaw 是基于 Node.js 的框架对版本有明确要求当前主流版本要求 Node 18 或 20。运行node -v看看输出如果版本过低需要从 Node 官网下载 LTS 版重新安装。这里尤其要提醒OpenClaw 安装教程里强调要用 Node.js 官网下载的版本不要用 Ubuntu 自带 apt 源里的老版本因为 apt 源版本往往落后会导致某些模块加载失败。我见过一种情况用户把整个目录从~/openclaw复制到/mnt/c/Users/xxx/openclawWindows 这边跑 Companion 时读取的配置没问题但 WSL 里启动网关时Node 在/mnt/c下扫描 node_modules 突然变慢等到超时直接退出。这种情况不算 1006 的根因但会加剧问题——排查时最好先把目录迁回 WSL 原生文件系统比如~/openclaw排除掉文件系统性能因素再继续。2.2 配置文件里指向的路径还是不是旧路径这是我最想让你重视的检查点。OpenClaw 的配置体系里有几个路径字段是网关启动时必须要读的配置文件本身的位置、数据存储目录、日志输出目录、会话临时目录。修改运行目录后最常见的翻车方式有两种第一种你只改了启动命令里的路径但配置文件中仍然是绝对路径。比如原来的配置写在/home/username/openclaw/.env里你把整个目录搬到了新位置.env里还是旧路径网关启动时去旧位置找数据目录当然找不到。第二种配置文件用的相对路径。相对路径的解析基准是当前工作目录而不是配置文件所在目录。如果你把运行目录改了但启动服务时的工作目录没改或者反过来都会导致解析到错误的目录。检查方法很简单进入 OpenClaw 配置目录打开.env或config.yaml找到所有DIR、PATH、DATA结尾的字段逐一核对这些路径是否真实存在。用ls -la逐级确认不要想当然。另外说一个最容易忽略的有些版本会在配置里写入host和port字段。如果你改目录时不小心动过这些参数或者从旧配置复制过来端口改了但 Windows Companion 里还是默认端口连接自然失败。确认一下port字段OpenClaw 网关默认一般在 3000 左右具体看版本千万别让两个服务端口打架。2.3 端口、防火墙和监听地址那些看不见的拦路虎归根结底gateway closed是连接层的问题。就算配置全对、WSL 环境正常只要端口不通客户端照样收到 1006。而且这个环节的坑往往最隐形因为服务进程可能确实起来了日志里也看不到报错但外部就是连不上。先看监听地址。在 WSL 里运行ss -tlnp | grep 3000端口换成你配置里的端口看输出结果里监听地址是127.0.0.1还是0.0.0.0。如果监听的是127.0.0.1那只有 WSL 内部能访问Windows 这边的 Companion 是连不上的必须把监听地址改成0.0.0.0或::。再查防火墙。Windows 防火墙对 WSL 的 Hyper-V 虚拟网卡有隔离策略经常出现 WSL 里服务正常、但 Windows 侧程序无法访问的情况。在 PowerShell 里用管理员身份跑New-NetFirewallRule -DisplayName WSL -Direction Inbound -InterfaceAlias vEthernet (WSL) -Action Allow给 WSL 虚拟网卡开个入站放行。注意这是给整个 WSL 网卡放行如果你之前有精细的端口规则也可以只针对端口开。最后检查端口占用。如果 3000 端口被你之前跑的其他服务占了OpenClaw 网关会启动失败或者换端口。运行netstat -ano | findstr :3000看看是不是有 PID 在监听如果有且不是 OpenClaw 进程改掉 OpenClaw 配置里的端口或者停掉占用进程。3. 修复实操完整恢复网关连接的三步走3.1 第一步把 OpenClaw 服务拉回默认状态别在错误状态上修补修改运行目录后遇到 1006最忌讳的是在原目录上反复重启。正确做法是先彻底停掉服务回到一个干净的基线状态。流程是这样的先把所有相关进程停掉。Windows 这边退出 Companion任务管理器里结束进程WSL 里运行pkill -f openclaw和pkill -f node确保没有残留进程继续占用端口或锁住文件。接着把运行目录先还原到之前能用的状态。如果你还记得旧目录在哪先启动一次旧目录验证旧环境还能跑。这一步的目的是区分问题到底出在“目录迁移”还是“环境变化”。如果旧目录也报同样的 1006那就不是目录的问题是环境或配置坏了得往 WSL 和 Node 方向排查。如果旧目录正常说明问题确定出在迁移过程那就专心处理迁移。我强烈建议在迁移前做一件事给整个 OpenClaw 目录打包备份。tar -czf openclaw_backup.tar.gz ~/openclaw备份比复制更可靠而且保留权限和符号链接。很多人用cp -r复制目录结果符号链接变成普通文件、可执行权限丢失启动时链接触发失败白折腾半天。3.2 第二步在新目录下重新初始化配置而不是直接复制旧配置改目录时最容易犯的错误是把.env配置整个复制到新目录就完事。OpenClaw 的配置里包含了大量绝对路径和机器相关参数直接复制等于把旧机器的“指纹”带到了新环境。正确做法是用 OpenClaw 自带的初始化命令重新生成基础配置。在 WSL 里进入新目录运行npx openclaw init具体命令名以你安装的版本为准它会引导你重新选择数据目录、语言模型参数、端口等。初始化完成后再把你之前自定义的配置改回去比如模型 API Key、代理设置这些。这里有个关键点数据目录data 目录最好独立于代码目录。也就是说~/openclaw放代码~/openclaw_data放数据数据目录在配置里单独指定。这样以后想更新代码或换位置数据不会跟着乱跑。如果你之前没这么做借这次机会改造成独立数据目录绝对不亏。初始化完成之后改好端口和监听地址重新启动服务。启动命令一般是npx openclaw start或./openclaw start注意必须在配置文件的同级目录下运行否则相对路径配置又白改了。3.3 第三步用日志和实测验证握手别等到客户端报错才回头看服务启动后别急着连 Windows Companion先在 WSL 里确认网关真的活着。看启动日志正常启动应该会出现类似gateway started、websocket listening on ...、listening on port 3000的关键词。如果日志里出现EADDRINUSE、ENOENT、EACCES就说明端口占用、路径不存在或权限不够对应去解决。然后做一次端口连通性测试在 WSL 里运行curl -s http://127.0.0.1:3000/health或对应版本的健康检查路径看返回是否正常。再在 Windows PowerShell 里运行curl http://localhost:3000/health注意确认 Windows 里访问的是不是同一个 WSL 端口——这里涉及 WSL2 的 localhost 转发通常在 PowerShell 里直接访问 localhost 会被转发到 WSL 的对应端口但如果 WSL 的监听地址配置不对这个转发就失效。最后再启动 Windows Companion重新配对。如果还报 1006检查一下 Companion 的日志文件一般在%APPDATA%\OpenClaw或安装目录下看它尝试连接的地址和端口是否与网关配置一致。这里分享一个我在实际中百试百灵的招如果确认配置、端口都没问题仍然报 1006试着在 WSL 里重启一下 WSL 网络栈。sudo ip link set eth0 down sudo ip link set eth0 up有时是 WSL 的虚拟网卡状态异常导致连接中断。这招解决过两次我以为是 OpenClaw 本身问题的场景。3.4 顺带处理“无法安全验证”和 WSL 状态提示很多人在部署 OpenClaw 时还会遇到一条提示OpenClaw 无法安全验证 WSL2 环境请在 PowerShell 中运行wsl -- status解决报告的问题。这句话看着吓人其实指的就是 WSL 核心组件没装全或版本不对按前面说的wsl --status检查版本即可。如果wsl --status显示“默认版本2”但报错仍然存在通常是内核组件过期。在 PowerShell 里运行wsl --update更新 WSL 内核然后wsl --shutdown重启 WSL 服务。更新完再跑一次wsl --status确认没有任何红色警告。顺带说一句如果你想在 Windows 上装 OpenClaw 但还没有 WSL直接去微软官网装 WSL 就行不要在 PowerShell 里乱改系统配置。安装过程很简单wsl --install一条命令搞定默认装 Ubuntu。装完第一次启动要设置用户名密码全程不需要管理员权限额外操作。4. 常见问题速查与避坑心得4.1 WebSocket 错误码速查表1006 只是其中一个我在社区里见过很多朋友把 1006 和 1000、1001、1002 混为一谈其实它们的语义完全不同。整理一张表错误码含义常见场景1000正常关闭服务主动退出双方都发了 close frame1001正在离开服务端重启或客户端跳转页面主动断开1002协议错误数据不符合 WebSocket 协议规范1005未收到状态码连接关闭但没带状态码少见1006异常关闭无 close frame连接被强制中断多半是网络链路、进程崩溃或权限问题1007数据不一致收到非法 UTF-8 数据1009消息过大传输的数据超过框架限制记住一点1006 是唯一一个不携带任何关闭帧的状态码——它本就不该出现在日志里一旦出现必是异常。而其他错误码多少都对应着协议层的主动行为排查方向完全不同。4.2 修改目录时最容易踩的三个坑我得坦白说我自己掉进过这三个坑每个都花了不少时间爬出来。第一个坑直接把目录复制到 Windows 盘/mnt/c/...下跑。WSL 1 时代没有这个问题但 WSL2 是真正的虚拟化跨文件系统访问存在于 Hyper-V 的 9P 协议上IO 性能差、权限丢失、inotify 不生效。OpenClaw 依赖文件监听做热更新在/mnt/c下跑轻则启动慢重则直接服务崩溃。老老实实把目录放在 WSL 原生文件系统里Windows 侧想看文件用\\wsl$\Ubuntu\home\xxx\openclaw访问方便又安全。第二个坑复制时没有包含隐藏文件。.env、.git、.config这些隐藏文件很多时候决定了服务能否正常启动。用cp -r或共享文件夹同步时默认可能不带隐藏文件取决于工具。我就见过一个朋友只复制了显式目录结果.env没拷过去服务启动时找不到配置直接崩掉日志里全是Cannot find module和 1006。拷贝时务必检查是否包含隐藏文件推荐用cp -a保留完整属性。第三个坑忘记清掉旧的临时文件和锁文件。OpenClaw 在运行时会在数据目录或系统临时目录写一些.lock、.sock、.pid文件。直接复制目录会把旧的锁文件带到新环境服务启动时尝试读取锁文件发现进程不存在误判为已有实例在运行启动失败或拒绝连接。处理办法是在新目录下启动前手动清掉这些临时文件干净清爽。4.3 我的一次真实排查经历给你当参考那次也是把 OpenClaw 从默认目录迁到新盘符重启后 Windows Companion 疯狂报 1006。我当时按网上的建议改了配置、换了端口、重装了 Node全都没用。后来静下心看日志发现服务其实已经启动了但启动两秒后自动退出——原因是数据目录里的一个数据库文件路径在新环境找不到。那次的根因是我迁移数据时只复制了文件没有复制目录结构。数据库默认写在data/chroma下的嵌套目录里拷贝时有些空目录被跳过了程序初始化时去定位表结构文件路径不存在直接抛异常。解决办法很简单把完整目录结构包括空目录重新建好重启服务一切正常。这个教训让我养成了一个习惯任何服务迁移先用tree或find列出目录结构对比新旧两边的差异别只看文件数量。空目录在 Linux 下是有意义的某些程序就是靠目录存在与否来判断初始化状态。4.4 一条龙排查顺序按这个顺序查少走弯路把前面所有排查点串起来我整理出一套最适合从零排查 1006 的顺序照着做基本能覆盖九成场景WSL 先验证wsl --status确认版本是 2wsl -l -v确认发行版正在运行wsl --update更新到最新Node 环境确认node -v和npm -v确保版本满足 OpenClaw 要求配置路径核对打开配置文件把里面所有路径字段都检查一遍确认新目录下都能找到端口检查ss -tlnp看监听地址和端口确认不是127.0.0.1端口没有被别的进程占用防火墙放行PowerShell 里给 WSL 网卡或特定端口加防火墙规则日志定位启动服务后紧盯着日志输出确认出现 gateway 启动成功字样最终连通性验证先 WSL 内 curl再 Windows 里 curl最后才连 Companion这个顺序的精髓在于从底层往上层排查。很多人一上来就改配置、重装服务绕过了最底层的 WSL 和 Node 环境检查结果做了无用功。环境是根配置是枝叶根出问题枝叶怎么修都没用。5. 写在最后的个人体会折腾 OpenClaw 和 1006 报错的这段时间我对这个框架的底层通信机制算是摸了个底朝天。我的感受是OpenClaw 本身很强大但对运行环境的“洁癖”也很明显它对 WSL2 的依赖、对 Node 版本的敏感、对目录权限的严格要求都意味着你不能用“装个普通软件”的心态去部署它。修改运行目录这件事看起来只是换了个地方放文件实际上牵动的是配置解析、路径引用、文件系统权限、网络监听等多个环节的联合协作。任何一个环节没跟着变都会在连接层表现出 1006 这种看似莫名其妙的错误。如果你读到这里还在跟这个报错搏斗我最后再送一个技巧仔细检查一下你的~/.bashrc或~/.profile里有没有设置过跟 OpenClaw 相关的环境变量比如OPENCLAW_HOME、DATA_DIR这种。这类环境变量的设置往往藏在你不注意的地方换个终端启动服务就可能生效失效不一样排查 1006 时很少有人想到这一层但偏偏就是它让我的服务“时好时坏”。希望这篇基于真实踩坑经验整理的文章能帮你少走几个弯路。如果你按上面的顺序排查完还解决不了大概率是版本特有 bug——去看看 OpenClaw 官方的 Release Notes有些版本提交里明确写着修正了 gateway 异常关闭问题。换个版本也许就安静了。 
长河君 · 2026/10/2 21:34:28 · 阅读 1.2k OpenClaw网关1006报错排查：WSL2目录迁移与WebSocket连接修复
先把结论放前面这个报错我排查了一整天才彻底解决原因比想象中隐蔽但解决思路其实就那么几条。如果你正在给 OpenClaw 换运行目录、搬数据盘或者刚装完 Windows Companion 准备连 WSL 里的网关突然看到gateway closed (1006 abnormal closure (no close frame)别慌这篇文章就是给你写的。我会从网关工作原理讲起再带你一步步排查配置、环境、端口和权限最后给出一套可以直接抄作业的修复流程。无论你是刚接触 OpenClaw 的小白还是已经被这个 1006 折磨到想砸键盘的老手按这个顺序查大概率能在半小时内恢复连接。1. 先搞懂 OpenClaw 的网关在整条链路里是什么角色1.1 OpenClaw 的部署形态WSL 里跑服务Windows 这边做桥接OpenClaw 是那种典型的控制台在云端、执行在本地的 AI 助理框架它由多个进程配合工作。最常见的一套跑法是WSL2 的 Ubuntu 里跑核心服务我们常说的 gatewayWindows 这边跑一个 Companion 进程做桥接把消息平台的推送转给 WSL 里的网关处理。网关gateway这个词本身很形象它就像大厦的总机接线员——所有外部消息要进来必须先打到总机再由总机转给对应的分机工具调用、技能执行、知识库查询。如果总机断了外部就完全联系不上里面的分机表现就是消息发不出去、工具调用无响应而日志里往往就躺着gateway closed (1006 abnormal closure (no close frame)。修改运行目录之所以会牵动网关是因为 OpenClaw 的服务启动时需要依赖配置文件去定位数据目录、日志目录、临时文件目录、会话存储等。一旦你改了目录但没同步更新配置或者新目录的权限、路径格式有问题网关进程会在启动早期“带病运行”随后在某次读取文件或建立 WebSocket 连接时直接崩掉表现就是 1006——异常关闭没有任何 close frame。1.2 1006 到底是什么意思连接被“硬掐断”而非“礼貌告别”WebSocket 协议里连接关闭分两种正常关闭会发送一个 close frame关闭帧里面带着状态码和原因比如 1000 表示 normal closure。而 1006 是极其特殊的一个码——它不是从远端收到的而是本地检测到连接异常中断后由 WebSocket 实现自己生成的状态码意思是“我根本没收到对方的 close frame连接就断了”。这就好比两个人在打电话正常挂机会听到“嘟”一声然后通话结束1006 就是电话打着打着突然信号中断你完全不知道对面发生了什么。所以排查 1006 时我们不能指望日志里给出原因码必须自己去检查底层的连接链路、进程状态和配置正确性。结合我遇到的情况和社区里其他人的反馈1006 出现的原因通常集中在以下几类网关进程启动后因为配置错误、权限错误或崩溃而退出导致连接被动断掉修改运行目录后配置里指向的路径已失效服务启动到一半读取不到关键文件直接退出WSL 环境异常比如 WSL 没正常启动、版本不对、Node 环境缺失服务根本没起来端口被占用或被防火墙拦截握手过程中连接被中途切断2. 从报错现场反向排查三个关键检查点2.1 修改运行目录后第一件事是确认 WSL 环境还健康很多人改目录时从来不碰 WSL觉得环境不会有事但实际恰恰相反。如果你把 OpenClaw 的运行目录从 WSL 原生的~\openclaw迁到了/mnt/c/...挂载的 Windows 盘符文件系统类型和权限模型会完全不同。WSL 里跨文件系统操作有很多坑最常见的是权限位失效、元数据丢失甚至某些操作直接报Operation not permitted。先按这个顺序检查打开 PowerShell运行wsl --status看输出里 WSL 版本是否显示 2。如果显示的是 WSL 1那 1006 几乎可以提前下结论——WSL1 对 WebSocket 和网络转发的支持不完整很多场景下连接会不稳定加上你改了目录服务更容易启动失败。如果状态正常再运行wsl -l -v确认 Ubuntu 发行版处于 Running 状态。如果显示 Stopped用wsl --shutdown全部停掉再重新进入。注意wsl --shutdown会关闭所有发行版重启后等个十来秒再操作别急着启动服务。进到 WSL 里之后检查 Node.js 版本。OpenClaw 是基于 Node.js 的框架对版本有明确要求当前主流版本要求 Node 18 或 20。运行node -v看看输出如果版本过低需要从 Node 官网下载 LTS 版重新安装。这里尤其要提醒OpenClaw 安装教程里强调要用 Node.js 官网下载的版本不要用 Ubuntu 自带 apt 源里的老版本因为 apt 源版本往往落后会导致某些模块加载失败。我见过一种情况用户把整个目录从~/openclaw复制到/mnt/c/Users/xxx/openclawWindows 这边跑 Companion 时读取的配置没问题但 WSL 里启动网关时Node 在/mnt/c下扫描 node_modules 突然变慢等到超时直接退出。这种情况不算 1006 的根因但会加剧问题——排查时最好先把目录迁回 WSL 原生文件系统比如~/openclaw排除掉文件系统性能因素再继续。2.2 配置文件里指向的路径还是不是旧路径这是我最想让你重视的检查点。OpenClaw 的配置体系里有几个路径字段是网关启动时必须要读的配置文件本身的位置、数据存储目录、日志输出目录、会话临时目录。修改运行目录后最常见的翻车方式有两种第一种你只改了启动命令里的路径但配置文件中仍然是绝对路径。比如原来的配置写在/home/username/openclaw/.env里你把整个目录搬到了新位置.env里还是旧路径网关启动时去旧位置找数据目录当然找不到。第二种配置文件用的相对路径。相对路径的解析基准是当前工作目录而不是配置文件所在目录。如果你把运行目录改了但启动服务时的工作目录没改或者反过来都会导致解析到错误的目录。检查方法很简单进入 OpenClaw 配置目录打开.env或config.yaml找到所有DIR、PATH、DATA结尾的字段逐一核对这些路径是否真实存在。用ls -la逐级确认不要想当然。另外说一个最容易忽略的有些版本会在配置里写入host和port字段。如果你改目录时不小心动过这些参数或者从旧配置复制过来端口改了但 Windows Companion 里还是默认端口连接自然失败。确认一下port字段OpenClaw 网关默认一般在 3000 左右具体看版本千万别让两个服务端口打架。2.3 端口、防火墙和监听地址那些看不见的拦路虎归根结底gateway closed是连接层的问题。就算配置全对、WSL 环境正常只要端口不通客户端照样收到 1006。而且这个环节的坑往往最隐形因为服务进程可能确实起来了日志里也看不到报错但外部就是连不上。先看监听地址。在 WSL 里运行ss -tlnp | grep 3000端口换成你配置里的端口看输出结果里监听地址是127.0.0.1还是0.0.0.0。如果监听的是127.0.0.1那只有 WSL 内部能访问Windows 这边的 Companion 是连不上的必须把监听地址改成0.0.0.0或::。再查防火墙。Windows 防火墙对 WSL 的 Hyper-V 虚拟网卡有隔离策略经常出现 WSL 里服务正常、但 Windows 侧程序无法访问的情况。在 PowerShell 里用管理员身份跑New-NetFirewallRule -DisplayName WSL -Direction Inbound -InterfaceAlias vEthernet (WSL) -Action Allow给 WSL 虚拟网卡开个入站放行。注意这是给整个 WSL 网卡放行如果你之前有精细的端口规则也可以只针对端口开。最后检查端口占用。如果 3000 端口被你之前跑的其他服务占了OpenClaw 网关会启动失败或者换端口。运行netstat -ano | findstr :3000看看是不是有 PID 在监听如果有且不是 OpenClaw 进程改掉 OpenClaw 配置里的端口或者停掉占用进程。3. 修复实操完整恢复网关连接的三步走3.1 第一步把 OpenClaw 服务拉回默认状态别在错误状态上修补修改运行目录后遇到 1006最忌讳的是在原目录上反复重启。正确做法是先彻底停掉服务回到一个干净的基线状态。流程是这样的先把所有相关进程停掉。Windows 这边退出 Companion任务管理器里结束进程WSL 里运行pkill -f openclaw和pkill -f node确保没有残留进程继续占用端口或锁住文件。接着把运行目录先还原到之前能用的状态。如果你还记得旧目录在哪先启动一次旧目录验证旧环境还能跑。这一步的目的是区分问题到底出在“目录迁移”还是“环境变化”。如果旧目录也报同样的 1006那就不是目录的问题是环境或配置坏了得往 WSL 和 Node 方向排查。如果旧目录正常说明问题确定出在迁移过程那就专心处理迁移。我强烈建议在迁移前做一件事给整个 OpenClaw 目录打包备份。tar -czf openclaw_backup.tar.gz ~/openclaw备份比复制更可靠而且保留权限和符号链接。很多人用cp -r复制目录结果符号链接变成普通文件、可执行权限丢失启动时链接触发失败白折腾半天。3.2 第二步在新目录下重新初始化配置而不是直接复制旧配置改目录时最容易犯的错误是把.env配置整个复制到新目录就完事。OpenClaw 的配置里包含了大量绝对路径和机器相关参数直接复制等于把旧机器的“指纹”带到了新环境。正确做法是用 OpenClaw 自带的初始化命令重新生成基础配置。在 WSL 里进入新目录运行npx openclaw init具体命令名以你安装的版本为准它会引导你重新选择数据目录、语言模型参数、端口等。初始化完成后再把你之前自定义的配置改回去比如模型 API Key、代理设置这些。这里有个关键点数据目录data 目录最好独立于代码目录。也就是说~/openclaw放代码~/openclaw_data放数据数据目录在配置里单独指定。这样以后想更新代码或换位置数据不会跟着乱跑。如果你之前没这么做借这次机会改造成独立数据目录绝对不亏。初始化完成之后改好端口和监听地址重新启动服务。启动命令一般是npx openclaw start或./openclaw start注意必须在配置文件的同级目录下运行否则相对路径配置又白改了。3.3 第三步用日志和实测验证握手别等到客户端报错才回头看服务启动后别急着连 Windows Companion先在 WSL 里确认网关真的活着。看启动日志正常启动应该会出现类似gateway started、websocket listening on ...、listening on port 3000的关键词。如果日志里出现EADDRINUSE、ENOENT、EACCES就说明端口占用、路径不存在或权限不够对应去解决。然后做一次端口连通性测试在 WSL 里运行curl -s http://127.0.0.1:3000/health或对应版本的健康检查路径看返回是否正常。再在 Windows PowerShell 里运行curl http://localhost:3000/health注意确认 Windows 里访问的是不是同一个 WSL 端口——这里涉及 WSL2 的 localhost 转发通常在 PowerShell 里直接访问 localhost 会被转发到 WSL 的对应端口但如果 WSL 的监听地址配置不对这个转发就失效。最后再启动 Windows Companion重新配对。如果还报 1006检查一下 Companion 的日志文件一般在%APPDATA%\OpenClaw或安装目录下看它尝试连接的地址和端口是否与网关配置一致。这里分享一个我在实际中百试百灵的招如果确认配置、端口都没问题仍然报 1006试着在 WSL 里重启一下 WSL 网络栈。sudo ip link set eth0 down sudo ip link set eth0 up有时是 WSL 的虚拟网卡状态异常导致连接中断。这招解决过两次我以为是 OpenClaw 本身问题的场景。3.4 顺带处理“无法安全验证”和 WSL 状态提示很多人在部署 OpenClaw 时还会遇到一条提示OpenClaw 无法安全验证 WSL2 环境请在 PowerShell 中运行wsl -- status解决报告的问题。这句话看着吓人其实指的就是 WSL 核心组件没装全或版本不对按前面说的wsl --status检查版本即可。如果wsl --status显示“默认版本2”但报错仍然存在通常是内核组件过期。在 PowerShell 里运行wsl --update更新 WSL 内核然后wsl --shutdown重启 WSL 服务。更新完再跑一次wsl --status确认没有任何红色警告。顺带说一句如果你想在 Windows 上装 OpenClaw 但还没有 WSL直接去微软官网装 WSL 就行不要在 PowerShell 里乱改系统配置。安装过程很简单wsl --install一条命令搞定默认装 Ubuntu。装完第一次启动要设置用户名密码全程不需要管理员权限额外操作。4. 常见问题速查与避坑心得4.1 WebSocket 错误码速查表1006 只是其中一个我在社区里见过很多朋友把 1006 和 1000、1001、1002 混为一谈其实它们的语义完全不同。整理一张表错误码含义常见场景1000正常关闭服务主动退出双方都发了 close frame1001正在离开服务端重启或客户端跳转页面主动断开1002协议错误数据不符合 WebSocket 协议规范1005未收到状态码连接关闭但没带状态码少见1006异常关闭无 close frame连接被强制中断多半是网络链路、进程崩溃或权限问题1007数据不一致收到非法 UTF-8 数据1009消息过大传输的数据超过框架限制记住一点1006 是唯一一个不携带任何关闭帧的状态码——它本就不该出现在日志里一旦出现必是异常。而其他错误码多少都对应着协议层的主动行为排查方向完全不同。4.2 修改目录时最容易踩的三个坑我得坦白说我自己掉进过这三个坑每个都花了不少时间爬出来。第一个坑直接把目录复制到 Windows 盘/mnt/c/...下跑。WSL 1 时代没有这个问题但 WSL2 是真正的虚拟化跨文件系统访问存在于 Hyper-V 的 9P 协议上IO 性能差、权限丢失、inotify 不生效。OpenClaw 依赖文件监听做热更新在/mnt/c下跑轻则启动慢重则直接服务崩溃。老老实实把目录放在 WSL 原生文件系统里Windows 侧想看文件用\\wsl$\Ubuntu\home\xxx\openclaw访问方便又安全。第二个坑复制时没有包含隐藏文件。.env、.git、.config这些隐藏文件很多时候决定了服务能否正常启动。用cp -r或共享文件夹同步时默认可能不带隐藏文件取决于工具。我就见过一个朋友只复制了显式目录结果.env没拷过去服务启动时找不到配置直接崩掉日志里全是Cannot find module和 1006。拷贝时务必检查是否包含隐藏文件推荐用cp -a保留完整属性。第三个坑忘记清掉旧的临时文件和锁文件。OpenClaw 在运行时会在数据目录或系统临时目录写一些.lock、.sock、.pid文件。直接复制目录会把旧的锁文件带到新环境服务启动时尝试读取锁文件发现进程不存在误判为已有实例在运行启动失败或拒绝连接。处理办法是在新目录下启动前手动清掉这些临时文件干净清爽。4.3 我的一次真实排查经历给你当参考那次也是把 OpenClaw 从默认目录迁到新盘符重启后 Windows Companion 疯狂报 1006。我当时按网上的建议改了配置、换了端口、重装了 Node全都没用。后来静下心看日志发现服务其实已经启动了但启动两秒后自动退出——原因是数据目录里的一个数据库文件路径在新环境找不到。那次的根因是我迁移数据时只复制了文件没有复制目录结构。数据库默认写在data/chroma下的嵌套目录里拷贝时有些空目录被跳过了程序初始化时去定位表结构文件路径不存在直接抛异常。解决办法很简单把完整目录结构包括空目录重新建好重启服务一切正常。这个教训让我养成了一个习惯任何服务迁移先用tree或find列出目录结构对比新旧两边的差异别只看文件数量。空目录在 Linux 下是有意义的某些程序就是靠目录存在与否来判断初始化状态。4.4 一条龙排查顺序按这个顺序查少走弯路把前面所有排查点串起来我整理出一套最适合从零排查 1006 的顺序照着做基本能覆盖九成场景WSL 先验证wsl --status确认版本是 2wsl -l -v确认发行版正在运行wsl --update更新到最新Node 环境确认node -v和npm -v确保版本满足 OpenClaw 要求配置路径核对打开配置文件把里面所有路径字段都检查一遍确认新目录下都能找到端口检查ss -tlnp看监听地址和端口确认不是127.0.0.1端口没有被别的进程占用防火墙放行PowerShell 里给 WSL 网卡或特定端口加防火墙规则日志定位启动服务后紧盯着日志输出确认出现 gateway 启动成功字样最终连通性验证先 WSL 内 curl再 Windows 里 curl最后才连 Companion这个顺序的精髓在于从底层往上层排查。很多人一上来就改配置、重装服务绕过了最底层的 WSL 和 Node 环境检查结果做了无用功。环境是根配置是枝叶根出问题枝叶怎么修都没用。5. 写在最后的个人体会折腾 OpenClaw 和 1006 报错的这段时间我对这个框架的底层通信机制算是摸了个底朝天。我的感受是OpenClaw 本身很强大但对运行环境的“洁癖”也很明显它对 WSL2 的依赖、对 Node 版本的敏感、对目录权限的严格要求都意味着你不能用“装个普通软件”的心态去部署它。修改运行目录这件事看起来只是换了个地方放文件实际上牵动的是配置解析、路径引用、文件系统权限、网络监听等多个环节的联合协作。任何一个环节没跟着变都会在连接层表现出 1006 这种看似莫名其妙的错误。如果你读到这里还在跟这个报错搏斗我最后再送一个技巧仔细检查一下你的~/.bashrc或~/.profile里有没有设置过跟 OpenClaw 相关的环境变量比如OPENCLAW_HOME、DATA_DIR这种。这类环境变量的设置往往藏在你不注意的地方换个终端启动服务就可能生效失效不一样排查 1006 时很少有人想到这一层但偏偏就是它让我的服务“时好时坏”。希望这篇基于真实踩坑经验整理的文章能帮你少走几个弯路。如果你按上面的顺序排查完还解决不了大概率是版本特有 bug——去看看 OpenClaw 官方的 Release Notes有些版本提交里明确写着修正了 gateway 异常关闭问题。换个版本也许就安静了。