先把结论放前面：这个报错我排查了一整天才彻底解决，原因比想象中隐蔽，但解决思路其实就那么几条。如果你正在给 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 里跑核心服务（我们常说的 gateway），Windows 这边跑一个 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/openclaw，Windows 这边跑 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 frame |
| 1001 | 正在离开 | 服务端重启或客户端跳转页面，主动断开 |
| 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确认版本是 2，wsl -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 异常关闭问题。换个版本也许就安静了。