Mehrere Gateways

Die meisten Setups sollten ein Gateway verwenden, da ein einzelnes Gateway mehrere Messaging-Verbindungen und Agenten verarbeiten kann. Wenn Sie stärkere Isolation oder Redundanz benötigen (z. B. einen Rescue-Bot), führen Sie separate Gateways mit isolierten Profilen/Ports aus.

Beste empfohlene Einrichtung

Für die meisten Benutzer ist die einfachste Rescue-Bot-Einrichtung:

• den Haupt-Bot im Standardprofil behalten
• den Rescue-Bot mit --profile rescue ausführen
• einen vollständig separaten Telegram-Bot für das Rescue-Konto verwenden
• den Rescue-Bot auf einem anderen Basisport wie 19789 betreiben

Dadurch bleibt der Rescue-Bot vom Haupt-Bot isoliert, sodass er Debugging durchführen oder Konfigurationsänderungen anwenden kann, wenn der primäre Bot ausgefallen ist. Lassen Sie mindestens 20 Ports zwischen Basisports frei, damit die abgeleiteten Browser-/Canvas-/CDP-Ports niemals kollidieren.

Rescue-Bot-Schnellstart

Verwenden Sie dies als Standardweg, sofern Sie keinen guten Grund haben, etwas anderes zu tun:

# Rescue bot (separate Telegram bot, separate profile, port 19789)openclaw --profile rescue onboardopenclaw --profile rescue gateway install --port 19789

Wenn Ihr Haupt-Bot bereits läuft, ist das normalerweise alles, was Sie benötigen.

Während openclaw --profile rescue onboard:

• verwenden Sie das separate Telegram-Bot-Token
• behalten Sie das Profil rescue bei
• verwenden Sie einen Basisport, der mindestens 20 höher ist als der des Haupt-Bots
• akzeptieren Sie den standardmäßigen Rescue-Workspace, sofern Sie nicht bereits selbst einen verwalten

Wenn das Onboarding den Rescue-Dienst bereits für Sie installiert hat, ist das abschließende gateway install nicht erforderlich.

Warum das funktioniert

Der Rescue-Bot bleibt unabhängig, weil er über eigene Komponenten verfügt:

• Profil/Konfiguration
• Zustandsverzeichnis
• Workspace
• Basisport (plus abgeleitete Ports)
• Telegram-Bot-Token

Für die meisten Setups verwenden Sie ein vollständig separates Telegram-Bot für das Rescue-Profil:

• einfach auf Operatoren beschränkbar
• separates Bot-Token und separate Identität
• unabhängig von der Kanal-/App-Installation des Haupt-Bots
• einfacher DM-basierter Wiederherstellungsweg, wenn der Haupt-Bot defekt ist

Was --profile rescue onboard ändert

openclaw --profile rescue onboard verwendet den normalen Onboarding-Ablauf, schreibt aber alles in ein separates Profil.

In der Praxis bedeutet das, dass der Rescue-Bot eigene Komponenten erhält:

• Konfigurationsdatei
• Zustandsverzeichnis
• Workspace (standardmäßig ~/.openclaw/workspace-rescue)
• Name des verwalteten Dienstes

Die Eingabeaufforderungen sind ansonsten dieselben wie beim normalen Onboarding.

Allgemeine Multi-Gateway-Einrichtung

Das oben gezeigte Rescue-Bot-Layout ist die einfachste Standardeinstellung, aber dasselbe Isolationsmuster funktioniert für jedes Paar oder jede Gruppe von Gateways auf einem Host.

Für eine allgemeinere Einrichtung geben Sie jedem zusätzlichen Gateway ein eigenes benanntes Profil und einen eigenen Basisport:

# main (default profile)openclaw setupopenclaw gateway --port 18789 # extra gatewayopenclaw --profile ops setupopenclaw --profile ops gateway --port 19789

Wenn Sie möchten, dass beide Gateways benannte Profile verwenden, funktioniert das ebenfalls:

openclaw --profile main setupopenclaw --profile main gateway --port 18789 openclaw --profile ops setupopenclaw --profile ops gateway --port 19789

Dienste folgen demselben Muster:

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

Verwenden Sie den Rescue-Bot-Schnellstart, wenn Sie eine Fallback-Operator-Spur benötigen. Verwenden Sie das allgemeine Profilmuster, wenn Sie mehrere langlebige Gateways für verschiedene Kanäle, Mandanten, Workspaces oder Betriebsrollen benötigen.

Isolations-Checkliste

Halten Sie diese pro Gateway-Instanz eindeutig:

• OPENCLAW_CONFIG_PATH — Konfigurationsdatei pro Instanz
• OPENCLAW_STATE_DIR — Sitzungen, Zugangsdaten und Caches pro Instanz
• agents.defaults.workspace — Workspace-Root pro Instanz
• gateway.port (oder --port) — eindeutig pro Instanz
• abgeleitete Browser-/Canvas-/CDP-Ports

Wenn diese gemeinsam genutzt werden, kommt es zu Konfigurationsrennen und Portkonflikten.

Portzuordnung (abgeleitet)

Basisport = gateway.port (oder OPENCLAW_GATEWAY_PORT / --port).

• Port des Browser-Steuerungsdienstes = Basis + 2 (nur local loopback)
• Canvas-Host wird über den HTTP-Server des Gateways bereitgestellt (derselbe Port wie gateway.port)
• CDP-Ports des Browserprofils werden automatisch aus browser.controlPort + 9 .. + 108 zugewiesen

Wenn Sie eine dieser Einstellungen in der Konfiguration oder Umgebung überschreiben, müssen Sie sie pro Instanz eindeutig halten.

Browser-/CDP-Hinweise (häufige Fehlerquelle)

• Fixieren Sie browser.cdpUrl nicht auf dieselben Werte über mehrere Instanzen hinweg.
• Jede Instanz benötigt ihren eigenen Browser-Steuerungsport und CDP-Bereich (abgeleitet von ihrem Gateway-Port).
• Wenn Sie explizite CDP-Ports benötigen, setzen Sie browser.profiles.<name>.cdpPort pro Instanz.
• Remote-Chrome: verwenden Sie browser.profiles.<name>.cdpUrl (pro Profil, pro Instanz).

Manuelles env-Beispiel

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

Schnellprüfungen

openclaw gateway status --deepopenclaw --profile rescue gateway status --deepopenclaw --profile rescue gateway probeopenclaw statusopenclaw --profile rescue statusopenclaw --profile rescue browser status

Interpretation:

• gateway status --deep hilft dabei, veraltete launchd-/systemd-/schtasks-Dienste aus älteren Installationen zu erkennen.
• Warntext von gateway probe wie multiple reachable gateway identities detected wird nur erwartet, wenn Sie absichtlich mehr als ein isoliertes Gateway ausführen oder wenn OpenClaw nicht nachweisen kann, dass erreichbare Probe-Ziele dasselbe Gateway sind. Ein SSH-Tunnel, eine Proxy-URL oder eine konfigurierte Remote-URL zu demselben Gateway ist ein Gateway mit mehreren Transporten, selbst wenn sich die Transportports unterscheiden.

Verwandt

• Gateway-Runbook
• Gateway-Sperre
• Konfiguration