Melhor configuração recomendada
Para a maioria dos usuários, a configuração mais simples de bot de resgate é:- manter o bot principal no perfil padrão
- executar o bot de resgate em
--profile rescue - usar um bot do Telegram completamente separado para a conta de resgate
- manter o bot de resgate em uma porta base diferente, como
19789
Início rápido do bot de resgate
Use isto como o caminho padrão, a menos que você tenha um motivo forte para fazer outra coisa:openclaw --profile rescue onboard:
- use o token do bot do Telegram separado
- mantenha o perfil
rescue - use uma porta base pelo menos 20 acima da do bot principal
- aceite o workspace de resgate padrão, a menos que você já gerencie um por conta própria
gateway install
final não será necessário.
Por que isso funciona
O bot de resgate permanece independente porque tem seu próprio:- perfil/configuração
- diretório de estado
- workspace
- porta base (mais portas derivadas)
- token do bot do Telegram
- fácil de manter somente para operadores
- token e identidade de bot separados
- independente da instalação de canal/app do bot principal
- caminho simples de recuperação baseado em DM quando o bot principal está quebrado
O que --profile rescue onboard altera
openclaw --profile rescue onboard usa o fluxo normal de onboarding, mas grava
tudo em um perfil separado.
Na prática, isso significa que o bot de resgate recebe seu próprio:
- arquivo de configuração
- diretório de estado
- workspace (por padrão
~/.openclaw/workspace-rescue) - nome de serviço gerenciado
Configuração geral de múltiplos Gateways
O layout de bot de resgate acima é o padrão mais fácil, mas o mesmo padrão de isolamento funciona para qualquer par ou grupo de Gateways em um host. Para uma configuração mais geral, dê a cada Gateway extra seu próprio perfil nomeado e sua própria porta base:Checklist de isolamento
Mantenha estes itens exclusivos por instância de Gateway:OPENCLAW_CONFIG_PATH— arquivo de configuração por instânciaOPENCLAW_STATE_DIR— sessões, credenciais e caches por instânciaagents.defaults.workspace— raiz do workspace por instânciagateway.port(ou--port) — exclusiva por instância- portas derivadas de navegador/canvas/CDP
Mapeamento de portas (derivadas)
Porta base =gateway.port (ou OPENCLAW_GATEWAY_PORT / --port).
- porta do serviço de controle do navegador = base + 2 (somente loopback)
- o host do canvas é servido no servidor HTTP do Gateway (mesma porta que
gateway.port) - as portas CDP do perfil de navegador são alocadas automaticamente a partir de
browser.controlPort + 9 .. + 108
Notas sobre navegador/CDP (armadilha comum)
- Não fixe
browser.cdpUrlnos mesmos valores em várias instâncias. - Cada instância precisa da sua própria porta de controle do navegador e intervalo CDP (derivados da porta do Gateway).
- Se você precisar de portas CDP explícitas, defina
browser.profiles.<name>.cdpPortpor instância. - Chrome remoto: use
browser.profiles.<name>.cdpUrl(por perfil, por instância).
Exemplo manual de env
Verificações rápidas
gateway status --deepajuda a detectar serviços launchd/systemd/schtasks obsoletos de instalações antigas.- O texto de aviso de
gateway probe, comomultiple reachable gateway identities detected, é esperado somente quando você executa intencionalmente mais de um gateway isolado, ou quando o OpenClaw não consegue provar que os destinos de sondagem alcançáveis são o mesmo gateway. Um túnel SSH, URL de proxy ou URL remota configurada para o mesmo gateway é um gateway com vários transportes, mesmo quando as portas de transporte diferem.