Skip to main content
Większość konfiguracji wymaga jednego Gateway — pojedynczy Gateway obsługuje wiele połączeń komunikatorów i agentów. Oddzielne Gateway z izolowanymi profilami/portami należy uruchamiać tylko wtedy, gdy potrzebna jest silniejsza izolacja lub nadmiarowość (np. bot ratunkowy).

​
Szybki start bota ratunkowego

Najprostsza konfiguracja bota ratunkowego:
  • Pozostaw głównego bota w profilu domyślnym.
  • Uruchom bota ratunkowego w --profile rescue, z jego własnym tokenem bota Telegram.
  • Ustaw dla bota ratunkowego inny port bazowy, np. 19789.
Dzięki temu bot ratunkowy może diagnozować problemy lub wprowadzać zmiany konfiguracji, jeśli główny bot nie działa. Zachowaj odstęp co najmniej 20 portów między portami bazowymi, aby pochodne porty przeglądarki/CDP nigdy ze sobą nie kolidowały.
Jeśli główny bot już działa, zwykle jest to wszystko, czego potrzeba. Jeśli proces wdrażania już zainstalował usługę ratunkową, pomiń końcowe gateway install. Podczas openclaw --profile rescue onboard:
  • Użyj oddzielnego tokenu bota Telegram, przeznaczonego dla konta ratunkowego (łatwo ograniczyć go wyłącznie do operatorów, jest niezależny od instalacji kanału/aplikacji głównego bota i zapewnia prostą ścieżkę odzyskiwania przez wiadomości prywatne).
  • Zachowaj nazwę profilu rescue.
  • Użyj portu bazowego wyższego o co najmniej 20 od portu głównego bota.
  • Zaakceptuj domyślny obszar roboczy bota ratunkowego, chyba że własny jest już zarządzany samodzielnie.

​
Co zmienia --profile rescue onboard

--profile rescue onboard uruchamia standardowy proces wdrażania, ale zapisuje wszystko w oddzielnym profilu, dzięki czemu bot ratunkowy otrzymuje własne:
  • Plik profilu/konfiguracji
  • Katalog stanu
  • Obszar roboczy (domyślnie: ~/.openclaw/workspace-rescue)
  • Nazwę zarządzanej usługi
  • Port bazowy (oraz porty pochodne)
  • Token bota Telegram
Pozostałe monity są identyczne jak podczas standardowego wdrażania.

​
Ogólna konfiguracja wielu Gateway

Ten sam wzorzec izolacji działa dla dowolnej pary lub grupy Gateway na jednym hoście — każdemu dodatkowemu Gateway należy nadać własny nazwany profil i port bazowy:
Nazwane profile po obu stronach również działają:
Usługi korzystają z tego samego wzorca:
Szybki start bota ratunkowego służy do utworzenia zapasowego kanału operatorskiego; ogólnego wzorca profili należy używać do obsługi wielu długotrwale działających Gateway w różnych kanałach, dzierżawach, obszarach roboczych lub rolach operacyjnych.

​
Lista kontrolna izolacji

Poniższe elementy muszą być unikatowe dla każdej instancji Gateway: Współdzielenie któregokolwiek z tych elementów powoduje konflikty konfiguracji, stanu lub portów. Podczas uruchamiania Gateway wymuszana jest unikatowa własność katalogu stanu, nawet gdy OPENCLAW_ALLOW_MULTI_GATEWAY=1 pomija ograniczenie do jednej instancji na konfigurację.

​
Mapowanie portów (pochodnych)

Port bazowy = gateway.port (lub OPENCLAW_GATEWAY_PORT / --port).
  • Port usługi sterowania przeglądarką = port bazowy + 2 (tylko interfejs pętli zwrotnej).
  • Host Canvas jest obsługiwany przez sam serwer HTTP Gateway (ten sam port co gateway.port).
  • Porty CDP profili przeglądarki są automatycznie przydzielane z zakresu od browser control port + 9 do + 108.
W przypadku zastąpienia któregokolwiek z tych ustawień w konfiguracji lub zmiennych środowiskowych należy zachować ich unikatowość dla każdej instancji.

​
Uwagi dotyczące przeglądarki/CDP (częsta pułapka)

  • Nie przypisuj browser.cdpUrl tej samej wartości w wielu instancjach.
  • Każda instancja wymaga własnego portu sterowania przeglądarką i zakresu CDP (pochodnych od jej portu Gateway).
  • Aby jawnie określić porty CDP, ustaw browser.profiles.<name>.cdpPort dla każdej instancji.
  • W przypadku zdalnej przeglądarki Chrome użyj browser.profiles.<name>.cdpUrl (dla każdego profilu i każdej instancji).

​
Przykład ręcznej konfiguracji zmiennych środowiskowych

​
Szybkie kontrole

  • gateway status --deep wykrywa nieaktualne usługi launchd/systemd/schtasks pozostałe po starszych instalacjach.
  • Tekst ostrzeżenia gateway probe, taki jak multiple reachable gateway identities detected, jest oczekiwany tylko wtedy, gdy celowo uruchamianych jest wiele izolowanych Gateway albo gdy OpenClaw nie może potwierdzić, że osiągalne cele sondowania są tym samym Gateway. Tunel SSH, adres URL serwera proxy lub skonfigurowany zdalny adres URL prowadzący do tego samego Gateway oznacza jeden Gateway z wieloma transportami, nawet jeśli porty transportów są różne.

​
Powiązane