Die meisten Setups sollten einen Gateway verwenden, da ein einzelner Gateway mehrere Messaging-Verbindungen und Agents bedienen 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.Documentation Index
Fetch the complete documentation index at: https://docs.openclaw.ai/llms.txt
Use this file to discover all available pages before exploring further.
Am besten empfohlenes Setup
Für die meisten Benutzer ist das einfachste Rescue-Bot-Setup:- den Haupt-Bot im Standardprofil belassen
- den Rescue-Bot mit
--profile rescueausführen - einen vollständig separaten Telegram-Bot für das Rescue-Konto verwenden
- den Rescue-Bot auf einem anderen Basis-Port wie
19789betreiben
Rescue-Bot-Schnellstart
Verwenden Sie dies als Standardweg, sofern Sie keinen triftigen Grund haben, etwas anderes zu tun:openclaw --profile rescue onboard:
- verwenden Sie das separate Telegram-Bot-Token
- behalten Sie das Profil
rescuebei - verwenden Sie einen Basis-Port, der mindestens 20 höher ist als der des Haupt-Bots
- akzeptieren Sie den standardmäßigen Rescue-Arbeitsbereich, sofern Sie nicht bereits selbst einen verwalten
gateway install nicht erforderlich.
Warum das funktioniert
Der Rescue-Bot bleibt unabhängig, weil er Folgendes jeweils separat hat:- Profil/Konfiguration
- Statusverzeichnis
- Arbeitsbereich
- Basis-Port (plus abgeleitete Ports)
- Telegram-Bot-Token
- einfach auf Operatoren beschränkbar
- separates Bot-Token und separate Identität
- unabhängig von der Channel-/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 Folgendes separat erhält:
- Konfigurationsdatei
- Statusverzeichnis
- Arbeitsbereich (standardmäßig
~/.openclaw/workspace-rescue) - Name des verwalteten Dienstes
Allgemeines Multi-Gateway-Setup
Das oben beschriebene Rescue-Bot-Layout ist der einfachste Standard, aber dasselbe Isolationsmuster funktioniert für jedes Paar oder jede Gruppe von Gateways auf einem Host. Für ein allgemeineres Setup geben Sie jedem zusätzlichen Gateway ein eigenes benanntes Profil und seinen eigenen Basis-Port:Isolations-Checkliste
Halten Sie diese Angaben pro Gateway-Instanz eindeutig:OPENCLAW_CONFIG_PATH— Konfigurationsdatei pro InstanzOPENCLAW_STATE_DIR— Sitzungen, Zugangsdaten, Caches pro Instanzagents.defaults.workspace— Arbeitsbereichsstamm pro Instanzgateway.port(oder--port) — eindeutig pro Instanz- abgeleitete Browser-/Canvas-/CDP-Ports
Portzuordnung (abgeleitet)
Basis-Port =gateway.port (oder OPENCLAW_GATEWAY_PORT / --port).
- Port des Browser-Steuerungsdienstes = Basis + 2 (nur local loopback)
- Canvas-Host wird auf dem Gateway-HTTP-Server bereitgestellt (derselbe Port wie
gateway.port) - CDP-Ports für Browserprofile werden automatisch aus
browser.controlPort + 9 .. + 108zugewiesen
Browser-/CDP-Hinweise (häufige Fehlerquelle)
- Setzen Sie
browser.cdpUrlnicht auf mehreren Instanzen auf dieselben Werte fest. - 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>.cdpPortpro Instanz. - Remote Chrome: verwenden Sie
browser.profiles.<name>.cdpUrl(pro Profil, pro Instanz).
Manuelles Umgebungsbeispiel
Schnellprüfungen
gateway status --deephilft, veraltete launchd-/systemd-/schtasks-Dienste aus älteren Installationen zu erkennen.- Warntext von
gateway probewiemultiple reachable gateways detectedwird nur erwartet, wenn Sie absichtlich mehr als einen isolierten Gateway ausführen.