在单个主机上运行多个OpenClaw Gateway实例时，必须使用隔离的profile（如 --profile rescue）、独立的基础端口（至少间隔20端口）以及各自的config、state和工作区。最简单的方案是搭建救援Bot：先为主Bot执行 openclaw onboard 和 gateway install，再为救援Bot执行 openclaw --profile rescue onboard --port 19789，并使用独立的Telegram Bot Token。端口映射规则：browser控制端口 = 基础端口 + 2，CDP端口从 controlPort + 9 到 +108 自动分配。切勿在不同实例间共享 browser.cdpUrl 或派生端口，否则会引发配置竞争和端口冲突。

OpenClaw 多Gateway实例：同一主机隔离、端口与profile设置

大多数场景一个Gateway就够了——单个Gateway能处理多个消息连接和智能体。只有需要更强隔离或冗余（例如一个可以独立诊断的救援Bot）时，才在同一主机运行多个Gateway实例。关键是每个实例必须拥有完全隔离的profile、配置和端口。

推荐方案：救援Bot快速搭建

最简单且经过验证的救援Bot方案是：

• 主Bot使用默认profile
• 救援Bot使用 --profile rescue
• 救援Bot使用另一个Telegram Bot token（完全独立）
• 救援Bot的基础端口与主Bot至少间隔20，例如主Bot用 18789，救援Bot用 19789

这样救援Bot与主Bot完全隔离，主Bot宕机时仍能正常调试或修改配置。

快速启动命令

# 救援Bot（独立Telegram bot、独立profile、端口19789）
openclaw --profile rescue onboard
openclaw --profile rescue gateway install --port 19789

如果主Bot已在运行，这两步通常就够了。

openclaw --profile rescue onboard 过程中：

• 使用独立的Telegram Bot token
• 保持 rescue profile
• 基础端口比主Bot至少高20
• 采用默认的救援工作区（除非你已自行管理）

如果onboarding已经帮安装了救援服务，最后的 gateway install 可以跳过。

为什么这样有效

救援Bot是独立的，因为它有自己的一套：

• profile/配置
• state目录
• 工作区（默认 ~/.openclaw/workspace-rescue）
• 基础端口（+派生端口）
• Telegram Bot token

对大多数场景，用完全独立的Telegram Bot做救援profile很方便：

• 只允许操作者访问
• 独立的bot token和身份
• 与主Bot的频道/应用安装无关
• 主Bot出问题时，通过DM做简单的恢复

--profile rescue onboard 改变了什么

openclaw --profile rescue onboard 走普通的onboarding流程，但把一切写入独立的profile。实际效果：

• 独立的配置文件
• 独立的state目录
• 独立的工作区（默认名带 -rescue 后缀）
• 独立的托管服务名（如 openclaw-rescue.service）

提示语与普通onboarding一致。

通用多Gateway方案

上面的救援Bot布局是最简单的默认方案，同样的隔离模式适用于任意成对或多组Gateway。

更通用的做法：给每个额外Gateway用独立的命名profile和独立的基础端口：

# 主实例（默认profile）
openclaw setup
openclaw gateway --port 18789

# 额外实例
openclaw --profile ops setup
openclaw --profile ops gateway --port 19789

如果两个Gateway都用命名profile也可以：

openclaw --profile main setup
openclaw --profile main gateway --port 18789

openclaw --profile ops setup
openclaw --profile ops gateway --port 19789

服务的安装也一样：

openclaw gateway install
openclaw --profile ops gateway install --port 19789

需要回退操作通道时用救援Bot快速启动；需要为不同渠道、租户、工作区或操作角色运行多个长期Gateway时用通用profile方案。

隔离清单

下面这些资源每个Gateway实例必须独占：

• OPENCLAW_CONFIG_PATH — 每个实例独立的配置文件
• OPENCLAW_STATE_DIR — 每个实例独立的会话、凭据、缓存
• agents.defaults.workspace — 每个实例独立的工作区根目录
• gateway.port（或 --port）— 每个实例唯一的端口
• 派生的浏览器/canvas/CDP端口

如果共享其中任何一项，会出现配置竞争和端口冲突。

端口映射（派生）

基础端口 = gateway.port（或 OPENCLAW_GATEWAY_PORT / --port）。

• 浏览器控制服务端口 = 基础端口 + 2（仅 loopback）
• Canvas主机由Gateway HTTP服务器提供（与 gateway.port 同端口）
• 浏览器profile的CDP端口从 browser.controlPort + 9 到 +108 自动分配

如果你在配置或环境变量中覆盖了任何派生端口，必须确保每个实例唯一。

浏览器/CDP常见坑点

• 不要 把 browser.cdpUrl 给多个实例设成相同的值。
• 每个实例需要自己的浏览器控制端口和CDP范围（从其Gateway端口派生）。
• 如果需要显式指定CDP端口，在每个实例中按profile设置 browser.profiles.<name>.cdpPort。
• 远程Chrome：使用 browser.profiles.<name>.cdpUrl（按profile、按实例）。

手动环境变量示例

OPENCLAW_CONFIG_PATH=~/.openclaw/main.json \
OPENCLAW_STATE_DIR=~/.openclaw \
openclaw gateway --port 18789

OPENCLAW_CONFIG_PATH=~/.openclaw/rescue.json \
OPENCLAW_STATE_DIR=~/.openclaw-rescue \
openclaw gateway --port 19789

快速检查

openclaw gateway status --deep
openclaw --profile rescue gateway status --deep
openclaw --profile rescue gateway probe
openclaw status
openclaw --profile rescue status
openclaw --profile rescue browser status

解读：

• gateway status --deep 有助于发现旧安装残留的launchd/systemd/schtasks服务。
• gateway probe 警告文本如 multiple reachable gateways detected 只应在你主动运行多个隔离Gateway时出现，属于正常。

相关文档

• Gateway 运行手册
• Gateway 锁
• 配置

常见问题

为什么需要一个以上的OpenClaw Gateway？

一个Gateway已经能连接多个消息渠道和智能体。但如果你需要一台机器上有完全独立的配置、state、工作区或bot身份（例如一个专用的监控Bot、隔离的工作环境、或者主Bot故障时的救援Bot），多Gateway是唯一的解决方案。各实例之间不会有任何资源干扰。

救援Bot和主Bot的端口怎么避免冲突？

主Bot和救援Bot的基础端口必须至少间隔20。例如主Bot用 18789，救援Bot用 19789。这样派生出的浏览器控制端口（基础+2）和CDP自动分配范围（controlPort+9到+108）就不会重叠。如果主Bot改了派生端口的值，间距要相应加大。

怎么检查多个OpenClaw Gateway实例是否都在正常运行？

通过带profile的status命令：

openclaw status                    # 查看主实例
openclaw --profile rescue status   # 查看救援实例
openclaw --profile rescue browser status   # 查看浏览器状态

用 gateway status --deep 检查是否有残留的旧服务进程。如果 gateway probe 提示“multiple reachable gateways detected”，只要是你有意运行多个实例就不用担心，这是正常结果。