Openclaw是真好玩儿！已经玩儿了大半个月了，欲罢不能，感觉还有很多可能没有发挥出来。肯定还要继续折腾的，不过这玩儿现在也真的是鲁棒性太差，很容易就玩儿挂了。于是决定开个帖子持续更新一下。

首先介绍下环境

我的是Oracle的免费vps，arm3核+18G内存+100G硬盘，跑这玩儿绰绰有余了。

目前遇到的主要问题并解决了的：

🔴 问题 1：网关进程假死导致端口冲突 (HTTP 502 / Port 18789 in use)

现象：
执行 openclaw gateway restart 失败，提示端口 18789 已被占用。手动 kill 进程后，系统底层的 systemd 会瞬间自动将其重启，导致陷入无限死循环，外部 Tailscale 请求无法被转交，报错 HTTP 502。
解决方案：
必须先切断系统的自动复活机制，清理残留端口，再重新安装服务。 github

# 1. 停止系统托管服务，避免其自动重启进程
systemctl --user stop openclaw-gateway.service

# 2. 强制终止残留的死锁进程，清理锁文件
openclaw gateway --force
rm -f ~/.openclaw/gateway.lock

# 3. 重新安装并拉起系统服务
openclaw gateway install --force
systemctl --user enable --now openclaw-gateway.service

🔴 问题 2：修改配置以消除 Tailscale 与本地安全警告

现象：
状态表 (openclaw status) 中出现 Reverse proxy headers are not trusted 等警告，并且无法正常信任 Tailscale 传来的请求。 fossies
解决方案：
将 OpenClaw 的网关绑定到本地，开启 Serve 模式，并信任本地环回代理。 openclaw

openclaw config set gateway.bind loopback
openclaw config set gateway.tailscale.mode serve
openclaw config set gateway.trustedProxies '["127.0.0.1", "::1"]'
openclaw config set gateway.controlUi.allowInsecureAuth false
openclaw gateway restart

🔴 问题 3：命令行设备 Token 丢失 (Missing scope / 1008 pairing required)

现象：
由于网关崩溃并经历了强制重装，之前的认证凭据损坏失效，CLI 和网页均提示 unreachable (missing scope: operator.admin) 或 1008 pairing required 。 github
解决方案：
通过清理旧的身份文件强制系统重新生成最高权限，或通过免验证模式进入后台生成长效 Token 。 github

# 方案 A：清理旧认证文件，让系统自动生成新的
rm -f ~/.openclaw/identity/device.json
rm -f ~/.openclaw/devices/paired.json
systemctl --user restart openclaw-gateway.service

# 方案 B：生成带最高权限的临时单次登录链接
openclaw dashboard --no-open
# 复制输出的 /#token=... 链接进行登录

🔴 问题 4：Tailscale Serve 转发失效 (502 Bad Gateway)

现象：
OpenClaw 已经在 18789 端口健康运行，但通过 Tailscale 域名访问依旧报 502 错误。
解决方案：
使用 Tailscale 最新的 CLI 语法，强行重置并映射后台 HTTPS 端口。

sudo tailscale serve reset
sudo tailscale serve --bg http://127.0.0.1:18789

🔴 问题 5：终极救命稻草：SSH 隧道直连访问

现象：
当外网、域名、反向代理全部崩溃时，需要一种 100% 能够进入控制台的备用方案。
解决方案：
利用 SSH 建立本地端口转发隧道。在 Windows 下，需要先右键私钥文件 属性 -> 安全 -> 高级，删除所有继承权限，仅授予当前用户“完全控制”权限，以防 SSH 报 WARNING: UNPROTECTED PRIVATE KEY FILE! 的安全错误。

ssh -i "你的私钥路径" -N -L 18789:127.0.0.1:18789 ubuntu@你的VPS公网IP

建立隧道后，直接在本地浏览器访问 http://localhost:18789/，这会被 OpenClaw 视为最高级别的本地安全访问，完全无需配对。

🔴 问题 6：外网设备 (手机) 的配对审批与浏览器兼容性

现象：
手机端 Tailscale 连通，但 Via 浏览器无法打开网页（因为自带的加密 DNS 和本地屏蔽规则破坏了 .ts.net 的内网解析）。换 Chrome 后成功打开页面，但提示 1008: pairing required。
解决方案：

避开使用强制公网 DNS 解析的轻量浏览器 (如 Via)，改用 Chrome。
手机属于“外部新设备”，需在电脑的 SSH 终端中进行手动授权审批，审批后便能永久通行：

# 查看有哪些设备在申请敲门
openclaw devices list

# 批准手机的连接申请（复制列表里的待审批 req_id）
openclaw devices approve <你的请求ID>

🧟 僵尸Gateway进程简报

📌 现象（What）

系统中有两个 openclaw-gateway 进程在同时运行：

PID	状态	CPU	内存	说明
2392085	正常	0.9%	471MB	系统服务（systemd管理）
2435254	僵尸	138%	336MB	孤儿进程，死循环中

⏰ 时间线（When）

02:16 — 正常gateway启动（PID 2392085）
04:10 — 僵尸gateway启动（PID 2435254），随后进入CPU死循环
当前 — 已持续占用CPU超过24小时

🔍 根本原因（Why & How）

核心原因：NotebookLM CLI 启动了一个独立的gateway实例。

过程还原：

你在终端执行了NotebookLM命令
NotebookLM（或某个脚本）启动了 openclaw-gateway 并指定：
- 端口：打码（而非默认的8080）
- Token：打码
这个实例不是通过systemd启动的，而是直接调用的
它与已运行的systemd服务冲突，陷入某种IO/网络等待的死循环

证据：

# 僵尸进程的环境变量
OPENCLAW_GATEWAY_PORT=打码
OPENCLAW_GATEWAY_TOKEN=打码

⚠️ 如何避免

NotebookLM使用时指定已有gateway：

export OPENCLAW_GATEWAY_URL="http://localhost:8080"
export OPENCLAW_GATEWAY_TOKEN="你主服务的token"
# 这样就不会自动启动新gateway

如果必须启动独立实例：

# 先停止systemd服务
sudo systemctl stop openclaw-gateway
# 再手动启动
openclaw-gateway --port 18789 &

使用完毕后清理：

# 杀死游离的gateway进程
killall openclaw-gateway
# 然后恢复systemd服务
sudo systemctl start openclaw-gateway

定期监控：

ps aux | grep openclaw-gateway | grep -v grep
# 如果看到多个gateway进程，那就是问题

关于上述的僵尸进程问题，一开始并没有彻底解决，然后又花了好久才处理掉。我觉得应该是我最开始安装埋下的锅。我是root权限安装，然后又迁移到user权限下，这个隐患一直没有解除掉。

整体来说，这次排错确实费了不少周折，但也彻底摸清了 OpenClaw 在 Linux/Ubuntu 下最容易踩坑的系统级机制。以下总结是这次核心故障点和最直接的终极解决方案，防止以后重蹈覆辙：

核心问题一：多版本网关服务冲突（端口霸占）

系统内同时存在两个网关守护进程在“神仙打架”。一个是旧版安装残留的系统级服务（名为 openclaw.service），另一个是我们新装的用户级服务（名为 openclaw-gateway.service）。由于旧版服务随系统率先启动并霸占了 18789 端口，导致新版服务虽然启动但无法对外提供连接，你在终端里看到的所有状态实际上都是那个旧版“僵尸进程”的伪装。 github

核心问题二：全局环境变量导致路径漂移

那个潜伏在系统底层的旧版服务，其配置文件 /etc/systemd/system/openclaw.service 中被硬编码写入了错误的全局变量 Environment="OPENCLAW_HOME=/home/ubuntu/.openclaw"。由于系统默认会在该变量指定的路径后再次拼接 .openclaw 作为工作区，这就导致了无论怎么删，系统都会源源不断地重新生成那个诡异的嵌套垃圾目录 /home/ubuntu/.openclaw/.openclaw/ 。 docs.openclaw

核心问题三：环境重置后的连接断代

在暴力清除了所有错乱的配置和进程后，网关和节点都恢复到了相当于“恢复出厂设置”的纯净状态。由于旧的设备身份令牌（Token）已不复存在，节点必须作为新设备重新向网关发起握手并申请授权，这就导致了连接初期的 pairing required 报错。 docs.openclaw

终极解决步骤汇总

如果未来再次遇到不明原因的 unreachable 或目录嵌套乱象，请直接按以下“四步走”执行物理级清理和重建：

斩杀系统级旧服务：

sudo systemctl stop openclaw.service
sudo systemctl disable openclaw.service
sudo rm -f /etc/systemd/system/openclaw.service
sudo systemctl daemon-reload

清理用户级服务与僵尸进程：

systemctl --user stop openclaw-gateway.service
systemctl --user stop openclaw-node.service
sudo pkill -9 -f openclaw
rm -rf /home/ubuntu/.openclaw/.openclaw/

重新安装纯净版服务：

openclaw gateway install --force
systemctl --user enable --now openclaw-gateway.service
sleep 3
openclaw node install --force
systemctl --user enable --now openclaw-node.service

重新批准设备配对：
运行 openclaw devices list 获取处于 pending 状态的请求 ID，然后执行 openclaw devices approve <Request ID> 签发新令牌。

顺便把迁移过程也总结下吧。还是对Linux系统不熟悉，如果是Windows的就没这么费劲了…

以下这是一份 OpenClaw 从 root 迁移至普通用户 (ubuntu) 的排错复盘记录。整个过程虽然踩了一些坑，但也暴露出 Node.js/AI 代理类应用在跨用户迁移时最容易遇到的核心痛点。

OpenClaw 跨用户迁移排错记录 (Root -> Ubuntu)

📌 核心痛点与主要问题

在将 OpenClaw 数据目录从 /root/.openclaw/ 物理移动到 /home/ubuntu/.openclaw/ 后，我们主要遭遇了以下三个层面的“连环报错”：

“Missing config” 无限重启循环
- 现象： 日志狂刷 Missing config. Run openclaw setup or set gateway.mode=local。
- 原因： 并非文件不存在，而是 Systemd 以新用户启动时，未能准确找到配置文件路径，或者配置文件内部缺失了最核心的 gateway 启动块。
端口冲突 (Port 18789 is already in use)
- 现象： Systemd 报错退出，日志显示 Gateway failed to start: gateway already running (pid xxx)。
- 原因： Systemd 在不断尝试重启 (Restart=always) 的过程中，由于权限或配置报错，导致旧的 Node.js 进程没有被干净地杀掉（变成了僵尸进程），一直霸占着 18789 端口，导致后续的新进程全军覆没。
“幽灵路径”导致的权限拒绝 (EACCES: permission denied)
- 现象： 即使所有环境变量都改了，在界面发消息或创建 Agent 时，依然报错试图创建目录 /root/.openclaw/agents/main/sessions。
- 原因： 即使指定了 $HOME，OpenClaw 系统中仍有优先级更高的配置文件（如 gateway.config.js）或本地 JSON 配置（openclaw.json 中的 workspace）硬编码了旧的 /root 绝对路径。程序顺着旧路径去写文件，被 Linux 权限系统拦截。

✅ 最终最有效的解决方案 (Checklist)

如果未来需要再次迁移或部署，按照以下四步即可一次性解决问题，避免踩坑：

第一步：彻底接管文件所有权

仅仅使用 mv 或 cp 移动文件是不够的，必须确保新用户拥有所有子目录（特别是 agents, workspace, sessions 等）的绝对控制权：

sudo chown -R ubuntu:ubuntu /home/ubuntu/.openclaw

第二步：排查所有的“硬编码”路径

不要只看环境变量，必须清理配置文件中残留的旧路径：

修改 JSON 文件 (/home/ubuntu/.openclaw/openclaw.json)：
确保 agents.defaults.workspace 等路径已经明确修改为 /home/ubuntu/.openclaw/workspace（切记不要乱加官方不支持的字段，如 storage）。
排查 JS 配置文件（隐形杀手）：
检查 /home/ubuntu/.openclaw/gateway.config.js，这个文件的优先级极高。如果里面硬编码了 /root，必须将其替换为 /home/ubuntu。

第三步：斩断端口占用的死循环

如果陷入了 Systemd 不断报错重启的死循环，不要直接改配置重启，必须先“净空”环境：

# 1. 停掉系统服务
sudo systemctl stop openclaw

# 2. 查出谁在占用 18789 端口并强制击杀 (替换 <PID>)
sudo lsof -i :18789
sudo kill -9 <PID>

第四步：构建“信息茧房”式的 Systemd 守护脚本

这是解决“服务找不到配置”的最有效手段。不要指望程序自己去猜路径，必须在 openclaw.service 中把所有路径环境变量显式锁死。

最稳妥的 /etc/systemd/system/openclaw.service 配置如下：

[Unit]
Description=OpenClaw Gateway Service
After=network.target

[Service]
Type=simple
User=ubuntu
Group=ubuntu
WorkingDirectory=/home/ubuntu
# 强制覆盖环境变量，彻底切断与 root 的联系
Environment="HOME=/home/ubuntu"
Environment="OPENCLAW_HOME=/home/ubuntu/.openclaw"
Environment="OPENCLAW_CONFIG_PATH=/home/ubuntu/.openclaw/openclaw.json"
# 启动命令
ExecStart=/usr/bin/openclaw gateway --verbose
Restart=always
RestartSec=3

[Install]
WantedBy=multi-user.target

(修改后需执行 sudo systemctl daemon-reload 和 sudo systemctl start openclaw)

💡 避坑经验总结

不要盲目删数据：遇到报错时，不要轻易删除已经生成的 agents 或 sessions 目录。问题通常出在“指路牌（路径配置）”指错了，而不是“房子（数据文件）”坏了。
正确使用 CLI 命令：读取配置不需要带 gateway，正确语法是 openclaw config get agents。
区分静态配置和运行时环境：排错时，如果 Systemd 起不来，可以使用 sudo -u ubuntu env -i HOME=/home/ubuntu ... 来模拟干净环境排查，直接定位是服务脚本写错了还是程序本身的 Bug。

遇到的问题目前还没有着手解决的：

如何修改主agent使用的模型：
之前一修改就挂掉，很诡异。
如何配置备用模型：
按说主模型失效后会访问备用模型，官方都是有配置方式的，但就是不生效。
如何设置多agent：
这个有思路，应该就是设置多个bot就可以。但不知道是否还有其它简便方式。
如何在agent下设置多session：
这个也有思路，就是首先让bot可以接受群信息，然后拉bot到不同群，并获取到群id，通过不同地群id设置多个session，不同session执行不同地工作。不过这样session是否可以配置不同模型？我看后台是可以选择的，但按照目前openclaw的操行，是否能生效，未知，需要调试。
如何设置一个主agent，然后让这个主agent根据任务特性来分配由哪个模型来完成任务。

宇宙中的粒子

持续折腾open claw