Przejdź do głównej treści

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.

Użyj tej strony do uruchomienia usługi Gateway w dniu 1 oraz operacji w dniu 2.

Deep troubleshooting

Diagnostyka od objawu z dokładnymi sekwencjami poleceń i sygnaturami logów.

Configuration

Zadaniowy przewodnik konfiguracji + pełna dokumentacja konfiguracji.

Secrets management

Kontrakt SecretRef, zachowanie migawki środowiska uruchomieniowego oraz operacje migrate/reload.

Secrets plan contract

Dokładne reguły celu/ścieżki secrets apply oraz zachowanie profilu uwierzytelniania tylko przez odwołania.

5-minutowe uruchomienie lokalne

1

Start the Gateway

openclaw gateway --port 18789
# debug/trace mirrored to stdio
openclaw gateway --port 18789 --verbose
# force-kill listener on selected port, then start
openclaw gateway --force
2

Verify service health

openclaw gateway status
openclaw status
openclaw logs --follow
Zdrowa baza: Runtime: running, Connectivity probe: ok oraz Capability: ... zgodne z oczekiwaniami. Użyj openclaw gateway status --require-rpc, gdy potrzebujesz dowodu RPC w zakresie odczytu, a nie tylko osiągalności.
3

Validate channel readiness

openclaw channels status --probe
Przy osiągalnym Gateway uruchamia to sondy kanałów na żywo dla każdego konta oraz opcjonalne audyty. Jeśli Gateway jest nieosiągalny, CLI zamiast wyników sond na żywo wraca do podsumowań kanałów tylko na podstawie konfiguracji.
Przeładowanie konfiguracji Gateway obserwuje aktywną ścieżkę pliku konfiguracji (rozwiązaną z domyślnych ustawień profilu/stanu albo z OPENCLAW_CONFIG_PATH, gdy jest ustawione). Domyślny tryb to gateway.reload.mode="hybrid". Po pierwszym udanym wczytaniu działający proces obsługuje aktywną migawkę konfiguracji w pamięci; udane przeładowanie atomowo podmienia tę migawkę.

Model środowiska uruchomieniowego

  • Jeden stale działający proces do routingu, płaszczyzny sterowania i połączeń kanałów.
  • Pojedynczy multipleksowany port dla:
    • sterowania/RPC przez WebSocket
    • API HTTP zgodnych z OpenAI (/v1/models, /v1/embeddings, /v1/chat/completions, /v1/responses, /tools/invoke)
    • interfejsu sterowania i hooków
  • Domyślny tryb wiązania: loopback.
  • Uwierzytelnianie jest domyślnie wymagane. Konfiguracje ze współdzielonym sekretem używają gateway.auth.token / gateway.auth.password (albo OPENCLAW_GATEWAY_TOKEN / OPENCLAW_GATEWAY_PASSWORD), a konfiguracje reverse proxy poza loopback mogą używać gateway.auth.mode: "trusted-proxy".

Endpointy zgodne z OpenAI

Najważniejsza powierzchnia zgodności OpenClaw to teraz:
  • GET /v1/models
  • GET /v1/models/{id}
  • POST /v1/embeddings
  • POST /v1/chat/completions
  • POST /v1/responses
Dlaczego ten zestaw ma znaczenie:
  • Większość integracji Open WebUI, LobeChat i LibreChat najpierw sprawdza /v1/models.
  • Wiele potoków RAG i pamięci oczekuje /v1/embeddings.
  • Klienci natywni dla agentów coraz częściej preferują /v1/responses.
Uwaga planistyczna:
  • /v1/models jest ukierunkowane na agenty: zwraca openclaw, openclaw/default i openclaw/<agentId>.
  • openclaw/default to stabilny alias, który zawsze mapuje się na skonfigurowanego agenta domyślnego.
  • Użyj x-openclaw-model, gdy chcesz nadpisać dostawcę/model backendu; w przeciwnym razie wybrany agent zachowuje kontrolę nad swoim zwykłym modelem i konfiguracją embeddingów.
Wszystkie te endpointy działają na głównym porcie Gateway i używają tej samej granicy zaufanego uwierzytelniania operatora co reszta API HTTP Gateway.

Priorytet portu i wiązania

UstawienieKolejność rozwiązywania
Port Gateway--portOPENCLAW_GATEWAY_PORTgateway.port18789
Tryb wiązaniaCLI/override → gateway.bindloopback
Zainstalowane usługi Gateway zapisują rozwiązany --port w metadanych nadzorcy. Po zmianie gateway.port uruchom openclaw doctor --fix albo openclaw gateway install --force, aby launchd/systemd/schtasks uruchamiał proces na nowym porcie. Uruchomienie Gateway używa tego samego efektywnego portu i wiązania, gdy inicjuje lokalne źródła interfejsu sterowania dla wiązań poza loopback. Na przykład --bind lan --port 3000 inicjuje http://localhost:3000 i http://127.0.0.1:3000, zanim zostanie uruchomiona walidacja środowiska uruchomieniowego. Dodaj jawnie wszelkie źródła zdalnych przeglądarek, takie jak adresy URL proxy HTTPS, do gateway.controlUi.allowedOrigins.

Tryby gorącego przeładowania

gateway.reload.modeZachowanie
offBrak przeładowania konfiguracji
hotZastosuj tylko zmiany bezpieczne na gorąco
restartUruchom ponownie przy zmianach wymagających przeładowania
hybrid (domyślnie)Zastosuj na gorąco, gdy bezpieczne; uruchom ponownie, gdy wymagane

Zestaw poleceń operatora

openclaw gateway status
openclaw gateway status --deep   # adds a system-level service scan
openclaw gateway status --json
openclaw gateway install
openclaw gateway restart
openclaw gateway stop
openclaw secrets reload
openclaw logs --follow
openclaw doctor
gateway status --deep służy do dodatkowego wykrywania usług (LaunchDaemons/jednostki systemowe systemd/schtasks), a nie do głębszej sondy kondycji RPC.

Wiele Gateway (ten sam host)

Większość instalacji powinna uruchamiać jeden Gateway na maszynę. Pojedynczy Gateway może obsługiwać wiele agentów i kanałów. Wiele Gateway jest potrzebnych tylko wtedy, gdy celowo chcesz izolacji albo bota ratunkowego. Przydatne kontrole:
openclaw gateway status --deep
openclaw gateway probe
Czego oczekiwać:
  • gateway status --deep może zgłosić Other gateway-like services detected (best effort) i wypisać wskazówki czyszczenia, gdy przestarzałe instalacje launchd/systemd/schtasks nadal istnieją.
  • gateway probe może ostrzec o multiple reachable gateways, gdy odpowiada więcej niż jeden cel.
  • Jeśli to celowe, izoluj porty, konfigurację/stan i katalogi główne obszarów roboczych dla każdego Gateway.
Lista kontrolna dla instancji:
  • Unikalny gateway.port
  • Unikalny OPENCLAW_CONFIG_PATH
  • Unikalny OPENCLAW_STATE_DIR
  • Unikalny agents.defaults.workspace
Przykład:
OPENCLAW_CONFIG_PATH=~/.openclaw/a.json OPENCLAW_STATE_DIR=~/.openclaw-a openclaw gateway --port 19001
OPENCLAW_CONFIG_PATH=~/.openclaw/b.json OPENCLAW_STATE_DIR=~/.openclaw-b openclaw gateway --port 19002
Szczegółowa konfiguracja: /gateway/multiple-gateways.

Dostęp zdalny

Preferowane: Tailscale/VPN. Awaryjnie: tunel SSH.
ssh -N -L 18789:127.0.0.1:18789 user@host
Następnie podłącz klientów lokalnie do ws://127.0.0.1:18789.
Tunele SSH nie omijają uwierzytelniania Gateway. W przypadku uwierzytelniania ze współdzielonym sekretem klienci nadal muszą wysyłać token/password nawet przez tunel. W trybach przenoszących tożsamość żądanie nadal musi spełnić tę ścieżkę uwierzytelniania.
Zobacz: Zdalny Gateway, Uwierzytelnianie, Tailscale.

Nadzór i cykl życia usługi

Używaj nadzorowanych uruchomień dla niezawodności zbliżonej do produkcyjnej.
openclaw gateway install
openclaw gateway status
openclaw gateway restart
openclaw gateway stop
Używaj openclaw gateway restart do ponownych uruchomień. Nie łącz openclaw gateway stop i openclaw gateway start jako zamiennika restartu.Na macOS gateway stop domyślnie używa launchctl bootout — usuwa to LaunchAgent z bieżącej sesji rozruchowej bez trwałego wyłączenia, więc automatyczne odzyskiwanie KeepAlive nadal działa po nieoczekiwanych awariach, a gateway start ponownie włącza usługę czysto. Aby trwale zatrzymać automatyczne ponowne uruchamianie między restartami systemu, przekaż --disable: openclaw gateway stop --disable.Etykiety LaunchAgent to ai.openclaw.gateway (domyślnie) albo ai.openclaw.<profile> (nazwany profil). openclaw doctor audytuje i naprawia rozjazdy konfiguracji usługi.

Szybka ścieżka profilu deweloperskiego

openclaw --dev setup
openclaw --dev gateway --allow-unconfigured
openclaw --dev status
Wartości domyślne obejmują izolowany stan/konfigurację oraz bazowy port Gateway 19001.

Szybka referencja protokołu (widok operatora)

  • Pierwsza ramka klienta musi być connect.
  • Gateway zwraca migawkę hello-ok (presence, health, stateVersion, uptimeMs, limity/polityka).
  • hello-ok.features.methods / events to konserwatywna lista wykrywania, a nie wygenerowany zrzut każdej możliwej do wywołania trasy pomocniczej.
  • Żądania: req(method, params)res(ok/payload|error).
  • Typowe zdarzenia obejmują connect.challenge, agent, chat, session.message, session.tool, sessions.changed, presence, tick, health, heartbeat, zdarzenia cyklu życia parowania/zatwierdzania oraz shutdown.
Uruchomienia agentów są dwuetapowe:
  1. Natychmiastowe potwierdzenie przyjęcia (status:"accepted")
  2. Końcowa odpowiedź zakończenia (status:"ok"|"error"), z przesyłanymi po drodze zdarzeniami agent.
Zobacz pełną dokumentację protokołu: Protokół Gateway.

Kontrole operacyjne

Żywotność

  • Otwórz WS i wyślij connect.
  • Oczekuj odpowiedzi hello-ok z migawką.

Gotowość

openclaw gateway status
openclaw channels status --probe
openclaw health

Odzyskiwanie po lukach

Zdarzenia nie są odtwarzane. Przy lukach w sekwencji odśwież stan (health, system-presence) przed kontynuacją.

Typowe sygnatury awarii

SygnaturaPrawdopodobny problem
refusing to bind gateway ... without authPowiązanie spoza pętli zwrotnej bez prawidłowej ścieżki uwierzytelniania Gateway
another gateway instance is already listening / EADDRINUSEKonflikt portu
Gateway start blocked: set gateway.mode=localKonfiguracja ustawiona na tryb zdalny albo w uszkodzonej konfiguracji brakuje znacznika trybu lokalnego
unauthorized during connectNiezgodność uwierzytelniania między klientem a Gateway
Pełne ścieżki diagnostyczne znajdziesz w Rozwiązywanie problemów z Gateway.

Gwarancje bezpieczeństwa

  • Klienci protokołu Gateway szybko kończą działanie, gdy Gateway jest niedostępny (bez niejawnego przełączania awaryjnego bezpośrednio na kanał).
  • Nieprawidłowe pierwsze ramki lub pierwsze ramki bez połączenia są odrzucane i zamykane.
  • Łagodne zamknięcie emituje zdarzenie shutdown przed zamknięciem gniazda.

Powiązane:

Powiązane