La maggior parte delle configurazioni dovrebbe usare un solo Gateway, perché un singolo Gateway può gestire più connessioni di messaggistica e agenti. Se hai bisogno di un isolamento o di una ridondanza maggiori (ad es. un bot di soccorso), esegui Gateway separati con profili/porte isolati.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.
Configurazione consigliata migliore
Per la maggior parte degli utenti, la configurazione più semplice del bot di soccorso è:- mantenere il bot principale sul profilo predefinito
- eseguire il bot di soccorso su
--profile rescue - usare un bot Telegram completamente separato per l’account di soccorso
- mantenere il bot di soccorso su una porta base diversa, ad esempio
19789
Avvio rapido del bot di soccorso
Usa questo come percorso predefinito, a meno che tu non abbia un motivo valido per fare qualcos’altro:openclaw --profile rescue onboard:
- usa il token del bot Telegram separato
- mantieni il profilo
rescue - usa una porta base almeno 20 più alta rispetto al bot principale
- accetta lo spazio di lavoro di soccorso predefinito, a meno che tu non ne gestisca già uno personalmente
gateway install non è necessario.
Perché funziona
Il bot di soccorso rimane indipendente perché ha i propri:- profilo/configurazione
- directory di stato
- spazio di lavoro
- porta base (più porte derivate)
- token del bot Telegram
- facile da mantenere riservato solo agli operatori
- token e identità del bot separati
- indipendente dall’installazione del canale/app del bot principale
- semplice percorso di recupero basato su DM quando il bot principale è guasto
Cosa cambia --profile rescue onboard
openclaw --profile rescue onboard usa il normale flusso di onboarding, ma
scrive tutto in un profilo separato.
In pratica, ciò significa che il bot di soccorso ottiene i propri:
- file di configurazione
- directory di stato
- spazio di lavoro (per impostazione predefinita
~/.openclaw/workspace-rescue) - nome del servizio gestito
Configurazione multi-Gateway generale
Il layout del bot di soccorso sopra è il predefinito più semplice, ma lo stesso modello di isolamento funziona per qualsiasi coppia o gruppo di Gateway su un host. Per una configurazione più generale, assegna a ogni Gateway aggiuntivo un profilo con nome e la propria porta base:Checklist di isolamento
Mantieni questi elementi univoci per ogni istanza di Gateway:OPENCLAW_CONFIG_PATH— file di configurazione per istanzaOPENCLAW_STATE_DIR— sessioni, credenziali e cache per istanzaagents.defaults.workspace— radice dello spazio di lavoro per istanzagateway.port(o--port) — univoca per istanza- porte derivate di browser/canvas/CDP
Mappatura delle porte (derivata)
Porta base =gateway.port (o OPENCLAW_GATEWAY_PORT / --port).
- porta del servizio di controllo del browser = base + 2 (solo loopback)
- l’host canvas viene servito sul server HTTP del Gateway (stessa porta di
gateway.port) - le porte CDP del profilo browser vengono allocate automaticamente da
browser.controlPort + 9 .. + 108
Note su browser/CDP (errore comune)
- Non fissare
browser.cdpUrlagli stessi valori su più istanze. - Ogni istanza richiede la propria porta di controllo del browser e il proprio intervallo CDP (derivati dalla sua porta Gateway).
- Se hai bisogno di porte CDP esplicite, imposta
browser.profiles.<name>.cdpPortper istanza. - Chrome remoto: usa
browser.profiles.<name>.cdpUrl(per profilo, per istanza).
Esempio di env manuale
Controlli rapidi
gateway status --deepaiuta a rilevare servizi launchd/systemd/schtasks obsoleti da installazioni precedenti.- il testo di avviso di
gateway probe, ad esempiomultiple reachable gateways detected, è previsto solo quando esegui intenzionalmente più di un gateway isolato.