刚装完 OpenClaw 2026.3.23，跑 openclaw configure 的时候让我装 Gateway 服务，我选了"Yes"。然后它就报错了。

Gateway service install failed: systemctl enable failed:  Failed to enable unit: Unit file openclaw-gateway.service does not exist.

翻译一下：它想把 Gateway 注册成 systemd 服务，但服务文件没创建成功，所以 systemctl enable 直接失败了。

跑 openclaw doctor 也是同样的结果，外加一个 Memory Search 的警告。整个 Gateway 起不来，等于 OpenClaw 瘫了。

为什么会这样

这个问题比微信插件那个要复杂一些，因为它涉及到 Linux 系统层面的东西。

OpenClaw 默认用的是 systemd 用户服务（systemctl --user）来管理 Gateway。这个设计本身没问题——不需要 root 权限，每个用户独立管理自己的服务。但 systemd 用户服务有几个前提条件，很多服务器环境不满足。

第一个条件：XDG_RUNTIME_DIR 这个环境变量得存在。

桌面 Linux 登录的时候，系统会自动设置这个变量，指向 /run/user/<你的uid>/。但如果你是通过 SSH 登录的 VPS，或者在 Docker 容器里，这个变量大概率不存在。

验证方法：

echo $XDG_RUNTIME_DIR

如果输出是空的，那就是没设置。

第二个条件：systemd linger 得开启。

默认情况下，你的 systemd 用户服务只在你登录期间运行。SSH 一断开，服务就跟着停了。loginctl enable-linger 可以改变这个行为，让服务在你注销后继续跑。对服务器来说这个是必须的。

验证方法：

loginctl show-user $USER -p Linger

输出 Linger=no 就是没开。

第三个条件：D-Bus 会话总线得可用。

systemd 用户服务之间通过 D-Bus 通信。有些精简安装的服务器可能没装 D-Bus，或者配置有问题。

OpenClaw 在执行 gateway install 的时候，会尝试创建服务文件到 ~/.config/systemd/user/openclaw-gateway.service，然后执行 systemctl --user daemon-reload 和 systemctl --user enable。如果上面三个条件有任何一个不满足，这个流程就会在某一步挂掉。

什么环境最容易中招

根据我自己和朋友们的经验，总结了一下：

• VPS（SSH 登录）：最容易出问题。基本上三个条件都不满足。

• Docker 容器：容器里通常没有完整的 systemd，这条路基本走不通。

• 最小化安装的 Ubuntu Server：看安装时选了哪些包，D-Bus 和 linger 可能都没配。

• WSL：取决于 WSL 版本，WSL2 新版本对 systemd 支持好一些。

• 桌面 Linux：一般没问题，登录管理器都帮你搞好了。

四种修法，看你的情况选

方案一：修好 systemd 环境

适合情况：你的服务器有 systemd，只是用户服务这块没配好。

# 设置 XDG_RUNTIME_DIR export XDG_RUNTIME_DIR="/run/user/$(id -u)" mkdir -p "$XDG_RUNTIME_DIR"  # 开启 linger loginctl enable-linger $USER  # 重新加载 systemd 用户配置 systemctl --user daemon-reload  # 重新安装 Gateway openclaw gateway install  # 检查一下 systemctl --user status openclaw-gateway.service

别忘了把 export XDG_RUNTIME_DIR="/run/user/$(id -u)" 加到 ~/.bashrc 里，不然下次登录又没了。

这个方案最"正规"。Gateway 作为 systemd 服务运行，开机自启，挂了自动重启，日志也能用 journalctl --user -u openclaw-gateway 查看。

方案二：直接后台跑

适合情况：不想折腾 systemd，或者环境不支持。

nohup openclaw gateway > /tmp/openclaw-gateway.log 2>&1 & echo $! > /tmp/openclaw-gateway.pid

两行搞定。nohup 保证 SSH 断开后进程不会被杀，输出重定向到日志文件。

缺点是重启服务器后需要手动启动。加个 crontab 可以解决：

(crontab -l 2>/dev/null; echo "@reboot nohup openclaw gateway > /tmp/openclaw-gateway.log 2>&1 &") | crontab -

管理起来也简单：

# 看日志 tail -f /tmp/openclaw-gateway.log  # 停掉 kill $(cat /tmp/openclaw-gateway.pid)  # 重启 kill $(cat /tmp/openclaw-gateway.pid); sleep 1 nohup openclaw gateway > /tmp/openclaw-gateway.log 2>&1 & echo $! > /tmp/openclaw-gateway.pid

这个方案最务实。不花哨，但管用。

方案三：写个系统级 systemd 服务

适合情况：你有 root 权限，想要生产级的稳定性。

和方案一的区别是：方案一用的是用户级服务（systemctl --user），这个方案用系统级服务（systemctl），不依赖用户登录状态。

cat > /etc/systemd/system/openclaw-gateway.service << 'EOF' [Unit] Description=OpenClaw Gateway After=network.target  [Service] Type=simple User=root WorkingDirectory=/root/.openclaw ExecStart=/root/.nvm/versions/node/v24.14.1/bin/node /root/.nvm/versions/node/v24.14.1/bin/openclaw gateway Restart=always RestartSec=5 Environment=HOME=/root Environment=NODE_ENV=production Environment=PATH=/root/.nvm/versions/node/v24.14.1/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin  [Install] WantedBy=multi-user.target EOF  systemctl daemon-reload systemctl enable openclaw-gateway systemctl start openclaw-gateway systemctl status openclaw-gateway

注意 ExecStart 里的路径要和你实际的 Node.js 安装路径对上。如果你用的不是 nvm，或者 Node.js 版本不同，改成你自己的路径。查看方法：

which node which openclaw

方案四：跑诊断脚本

适合情况：不确定到底哪里出了问题，想让脚本帮你查。

我们在排查这个问题的过程中写了一个诊断修复脚本（就是 /home/ubuntu/temp/fix-gateway.sh），它会从底层到高层逐项检查：

1. systemctl 装了没

2. systemd 跑起来没

3. XDG_RUNTIME_DIR 设了没

4. linger 开了没

5. systemd 用户会话通不通

6. Gateway 服务文件在不在

7. Gateway 服务跑起来没

8. Gateway 进程存不存在

9. 18789 端口有没有人占

每一项的结果都会记录下来，最后给你一份诊断报告。如果发现问题，会让你选修复方案。

chmod +x fix-gateway.sh ./fix-gateway.sh

脚本的设计思路是"先诊断，后修复"。诊断阶段只看不动，修复阶段让你确认了才执行。这样比较安全，不会在你不知情的情况下改系统配置。

顺便说一下 Memory Search 的问题

跑 openclaw doctor 的时候你可能还会看到这个：

Memory search is enabled, but no embedding provider is ready.

这个和 Gateway 是两个独立的问题。Memory Search 是 OpenClaw 的语义记忆功能，需要一个文本嵌入模型来做向量检索。如果你的模型提供商（比如 modelstudio）不支持 embedding API，这个功能就用不了。

两种处理方式：

# 方式一：关掉它（不影响基本功能） openclaw config set agents.defaults.memorySearch.enabled false  # 方式二：配一个支持 embedding 的 API key export OPENAI_API_KEY="你的key" # 然后重启 gateway

如果你暂时不需要语义记忆（就是让 AI 能"回忆"之前聊过的内容），关掉就行，不影响正常使用。

踩坑之后的一些感想

Gateway 装不上这个问题，表面上看是 systemd 报错，实际上是 OpenClaw 的安装流程对服务器环境考虑不够周全。大部分人跑 OpenClaw 都是在 VPS 上，而 VPS 的 systemd 用户服务环境几乎肯定是不完整的。

如果 openclaw gateway install 能在检测到 systemd 用户服务不可用的时候，自动回退到后台进程模式（就是方案二），那用户就不会被这个问题卡住了。

不过话说回来，这是 2026.3.23 版本，项目还在快速迭代中。从版本号的跳跃速度就能看出来，开发团队在猛加功能，边角料的打磨需要时间。

用测试版开源软件，心态很重要。 不要期待它像商业产品一样开箱即用。遇到问题是正常的，能自己修好才是关键。

我的习惯是每次踩坑都写一篇笔记存下来。几个月下来，这些笔记比官方文档都好使——因为它们都是从真实问题出发，在真实环境里验证过的。

给同样遇到问题的人

先别慌，看报错。 systemd 的报错信息已经说得很明确了——"Unit file does not exist"就是服务文件没创建成功。顺着这个线索去查就行。

确认你的环境。 如果是 VPS，大概率是 XDG_RUNTIME_DIR 和 linger 的问题。如果是 Docker，别跟 systemd 较劲了，直接用方案二。

选适合你的方案。 四种方案没有哪个绝对好——看你的环境、你的需求、你愿意花多少时间折腾。我个人偏好方案三（系统级 systemd 服务），稳定省心。

修好了告诉别人。 去 GitHub Issues 发一条，或者写篇博客。你踩过的坑，别人大概率也会踩。分享一下排查过程，可能帮到不少人。

到底值不值得折腾

有人可能会问：这么多问题，OpenClaw 到底靠不靠谱？

我的看法是：靠谱，但得调整期望。

它的架构设计是认真的——多智能体、插件化、多渠道路由，这些都不是玩具级别的东西。微信、WhatsApp、Telegram 三个渠道打通，加上自定义的工作区和记忆系统，功能已经相当完整了。

问题在于安装和配置环节还不够顺滑。但这是几乎所有早期开源项目的通病。你想想 Docker 刚出来的时候、Kubernetes 早期版本、甚至 VS Code 最初的几个版本——哪个不是用户一边骂一边帮着调试的？

好工具值得你花时间去折腾。能把 OpenClaw 跑起来、用起来的人，对底层系统的理解会深一个层次。这些经验在其他地方也用得上。

动手修问题这件事本身，就已经超过了大多数人。

解决的脚本下载：

我正通过联通云盘分享文件给您，请点击下面的链接，输入提取码获取文件

链接：https://pan.wo.cn/s/1o1V5t16182

提取码：plV9