Skip to main content
La maggior parte delle configurazioni richiede un solo Gateway: un singolo Gateway gestisce più connessioni di messaggistica e agenti. Eseguire Gateway separati con profili/porte isolati solo quando è necessario un isolamento più forte o una ridondanza (ad esempio, un bot di soccorso).

​
Avvio rapido del bot di soccorso

La configurazione più semplice per un bot di soccorso:
  • Mantenere il bot principale nel profilo predefinito.
  • Eseguire il bot di soccorso su --profile rescue, con un token bot Telegram dedicato.
  • Assegnare al bot di soccorso una porta di base diversa, ad esempio 19789.
In questo modo, il bot di soccorso può eseguire il debug o applicare modifiche alla configurazione se il bot principale non è disponibile. Lasciare almeno 20 porte tra le porte di base, affinché le porte derivate del browser/CDP non entrino mai in conflitto.
Se il bot principale è già in esecuzione, in genere non serve altro. Se l’onboarding ha già installato il servizio di soccorso, saltare il comando finale gateway install. Durante openclaw --profile rescue onboard:
  • Utilizzare un token bot Telegram separato, dedicato all’account di soccorso (facile da riservare agli operatori, indipendente dall’installazione del canale/app del bot principale e semplice percorso di ripristino basato sui messaggi diretti).
  • Mantenere il nome del profilo rescue.
  • Utilizzare una porta di base superiore di almeno 20 rispetto a quella del bot principale.
  • Accettare lo spazio di lavoro di soccorso predefinito, a meno che non se ne gestisca già uno autonomamente.

​
Cosa modifica --profile rescue onboard

--profile rescue onboard esegue il normale flusso di onboarding, ma scrive tutto in un profilo separato, così il bot di soccorso dispone di propri:
  • File di profilo/configurazione
  • Directory di stato
  • Spazio di lavoro (predefinito: ~/.openclaw/workspace-rescue)
  • Nome del servizio gestito
  • Porta di base (oltre alle porte derivate)
  • Token bot Telegram
Per il resto, le richieste sono identiche a quelle del normale onboarding.

​
Configurazione generale con più Gateway

Lo stesso schema di isolamento funziona per qualsiasi coppia o gruppo di Gateway su un unico host: assegnare a ogni Gateway aggiuntivo un profilo denominato e una porta di base dedicati:
È anche possibile utilizzare profili denominati per entrambi:
I servizi seguono lo stesso schema:
Utilizzare l’avvio rapido del bot di soccorso per un canale operativo di riserva; utilizzare lo schema generale dei profili per più Gateway a lunga esecuzione su canali, tenant, spazi di lavoro o ruoli operativi diversi.

​
Lista di controllo dell’isolamento

Mantenere univoci questi elementi per ogni istanza del Gateway: La condivisione di uno qualsiasi di questi elementi causa conflitti di configurazione, stato o porte. L’avvio del Gateway impone che ogni directory di stato abbia un proprietario univoco, anche quando OPENCLAW_ALLOW_MULTI_GATEWAY=1 ignora l’istanza singola per configurazione.

​
Mappatura delle porte (derivate)

Porta di 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 stesso (stessa porta di gateway.port).
  • Le porte CDP del profilo del browser vengono allocate automaticamente da browser control port + 9 a + 108.
Se uno qualsiasi di questi valori viene sovrascritto nella configurazione o nell’ambiente, deve rimanere univoco per ogni istanza.

​
Note su browser/CDP (errore comune)

  • Non impostare browser.cdpUrl sullo stesso valore per più istanze.
  • Ogni istanza richiede una porta di controllo del browser e un intervallo CDP propri (derivati dalla relativa porta del Gateway).
  • Per porte CDP esplicite, impostare browser.profiles.<name>.cdpPort per ogni istanza.
  • Per Chrome remoto, utilizzare browser.profiles.<name>.cdpUrl (per profilo e per istanza).

​
Esempio manuale con variabili d’ambiente

​
Controlli rapidi

  • gateway status --deep rileva i servizi launchd/systemd/schtasks obsoleti provenienti da installazioni precedenti.
  • Il testo di avviso di gateway probe, come multiple reachable gateway identities detected, è previsto solo quando si eseguono intenzionalmente più Gateway isolati oppure quando OpenClaw non può verificare che le destinazioni di probe raggiungibili corrispondano allo stesso Gateway. Un tunnel SSH, un URL proxy o un URL remoto configurato verso lo stesso Gateway rappresentano un unico Gateway con più trasporti, anche quando le porte di trasporto sono diverse.

​
Argomenti correlati