痛点拆解：云服务器上「能跑」，笔记本 WSL 上「像玄学」
痛点一：两个 127.0.0.1。文档写绑定回环最安全，但同事用手机测 webhook 永远打不到 WSL 里的监听端口，因为在 WSL2 里回环属于轻量虚拟机栈，不等同于 Windows 或路由器看到的接口。常见误判是「OpenClaw 坏了」，实际是入口叙事缺了一页图。
痛点二：复制来的 unit 不生效。把 VPS 上的 systemd 配置粘到 WSL，却发现从未被 PID 1 加载；人只好用 tmux 或开机脚本凑合，和你在 常驻矩阵里强调的生产纪律相冲突。
痛点三：休眠与 VPN 抖动。合盖、换网、公司 VPN 重连都会让长连接无声断裂；进程存活不等于通道健康，这与 网关运维文里「doctor 要与通道日志对表」的结论一致。
痛点四：TLS 终止点漂移。在 Windows 终止 TLS 再转发到 WSL 时，若 WebSocket 升级头或 allowedOrigins 处理不一致，会出现「CLI 正常、Bot 沉默」。应把边缘规则与 反向代理指南对照，而不是反复改模型参数。
痛点五：多份 Node 与 CLI。Windows 全局、WSL nvm、pnpm 路径混用会产生多个 openclaw；升级后 ExecStart 仍指向旧前缀，排障应从 安装与回滚核对绝对路径开始。
WSL2 网络命名空间：数据包到底落在哪张网卡
WSL2 运行在实用虚拟机中，发行版自有路由与地址。OpenClaw 在 Ubuntu 内监听 127.0.0.1 时，指的是该命名空间回环，不是 Windows 主机回环。反过来，只在 Windows 监听的服务也不会自动对 Linux 进程「透明可达」，除非按文档配置主机互通或转发。
部分 Windows 版本的镜像/共享本机模式只减轻部分互通，仍要写清回调 URL、证书与防火墙规则。
出站 NAT 常顺畅，故「能出站、入站 webhook 不稳」多属入站路径未闭合。
局域网调试除 WSL 绑 0.0.0.0 外还需 Windows portproxy 与防火墙；更稳妥是回环加反向代理，或把公网入口放到 SFTPMAC 托管远程 Mac。
DNS 分流会导致 OAuth 间歇失败；Windows 与 WSL 各查一次解析再判断。
systemd 与 WSL：让 unit 真正成为监督者
在支持的发行版上，通过 /etc/wsl.conf 的 [boot] 段启用 systemd=true，然后在 Windows 执行 wsl --shutdown 再启动实例，才能让 systemd 成为 PID 1。未重启前，文件写得再漂亮也只是静态文本。
启用后按服务器习惯配置 unit，并用 status → gateway → doctor → logs 阶梯验证。
注意 User、密钥路径；/mnt/c 上环境文件留意权限与 CRLF。
若禁用 systemd，需换有退避的监督器而非长期前台；见 常驻文。
journal 注意持久化与磁盘；升级前后留存 doctor 输出并对照 回滚手册。
决策矩阵：监听面、Windows 转发与反向代理
| 模式 | 优势 | 风险 | 适用 |
|---|---|---|---|
| 仅 WSL 回环 | 暴露面最小 | 外网与手机无法直测 | 纯本机 CLI 试验 |
| WSL 全接口 + Windows portproxy | 局域网可达路径清晰 | 易过度暴露；规则易忘 | 家庭实验 webhook |
| Windows 终止 TLS 指向上游 | 证书集中；边缘统一 | WebSocket 头与源校验易错 | 接近生产的桌面演练 |
| SSH 隧道回指 WSL | 无家庭公网监听 | 隧道不稳 | 个人实验 |
| 网关迁至托管远程 Mac | 电源与网络故事简单 | 供应商评估 | 重视稳定与 Apple 工具链的团队 |
| Docker Desktop | 镜像复现 | 再叠 NAT | 已 Compose 化团队 |
每环境一条主路径写清；半套回环半套局域网最耗值班。
命令阶梯：从 wsl.conf 到 doctor 证据链
# 1) 启用 systemd（示例片段，以发行版文档为准）
# sudo tee /etc/wsl.conf <<'EOF'
# [boot]
# systemd=true
# EOF
# 在 Windows：wsl --shutdown
# 2) 确认 init 与 unit
# ps -p 1 -o comm=
# systemctl status openclaw-gateway.service
# 3) 查看 WSL 内监听（端口示例）
# ss -lntp | head
# 4) Windows 端口转发示例（管理员 PowerShell；替换地址）
# netsh interface portproxy add v4tov4 listenport=8443 listenaddress=0.0.0.0 connectport=8443 connectaddress=<WSL-IP>
# 5) OpenClaw 诊断（子命令以版本为准）
# openclaw status
# openclaw gateway status
# openclaw doctor
# openclaw logs --follow
提工单请附五段输出；单张截图不够。
阅读顺序与相邻加固
顺序建议：安装 → 常驻 → 通道 → 代理；升级对照 回滚。
分层 doctor：每改 systemd、转发、证书、VPN 后重跑；doctor 通过仍掉线则查通道日志。
Slack 经公司代理时，写明代理变量如何进入 WSL，避免浏览器与网关分裂。
预发与生产保持同源同形，避免 allowedOrigins 上线才爆。
FAQ、边界与 SFTPMAC 托管远程 Mac 衔接
镜像网络能一劳永逸吗？
不能；仍要明确监听、防火墙与回调 URL，并用外部客户端验证。
doctor 通过但休眠后频道沉默？
对照 systemd 与系统休眠时间线，查通道是否卡死套接字；必要时调整依赖或重启网关。
生产网关适合笔记本吗？
一般不适合；应放长期在线或托管机。
已用 WSL 写代码，还要托管 Mac 吗？
可分工：本地 WSL 继续开发构建，OpenClaw 网关放到 SFTPMAC 托管远程 Mac，减少 Windows 侧转发与合盖风险，并与 SSH/SFTP 交付习惯衔接。
总结：WSL2 不是「在 Windows 里跑 Linux 文件」那么简单，而是多命名空间与可选 systemd 的组合；本机回环、转发与 TLS 终止必须命名，openclaw doctor 应分层执行并与通道日志对齐。
局限：Windows 版本与企业 VPN 组合无法穷尽；集成税过高时可迁网关至托管 macOS，桌面仍可用 WSL 开发。
若希望 OpenClaw 网关少踩 WSL 端口与睡眠坑，可评估 SFTPMAC 稳定远程 Mac 方案与 SFTP 工作流衔接。