The Gateway ist der WebSocket-Server von OpenClaw (Kanäle, Nodes, Sitzungen, Hooks). Unterbefehle auf dieser Seite befinden sich unterDocumentation Index
Fetch the complete documentation index at: https://docs.openclaw.ai/llms.txt
Use this file to discover all available pages before exploring further.
openclaw gateway ….
Bonjour discovery
Lokales mDNS + Wide-Area-DNS-SD-Setup.
Discovery overview
Wie OpenClaw Gateways ankündigt und findet.
Configuration
Gateway-Konfigurationsschlüssel auf oberster Ebene.
Gateway ausführen
Führen Sie einen lokalen Gateway-Prozess aus:Startup behavior
Startup behavior
- Standardmäßig verweigert der Gateway den Start, sofern
gateway.mode=localnicht in~/.openclaw/openclaw.jsonfestgelegt ist. Verwenden Sie--allow-unconfiguredfür Ad-hoc-/Dev-Ausführungen. openclaw onboard --mode localundopenclaw setupsollengateway.mode=localschreiben. Wenn die Datei existiert, abergateway.modefehlt, behandeln Sie dies als beschädigte oder überschriebene Konfiguration und reparieren Sie sie, statt den lokalen Modus implizit anzunehmen.- Wenn die Datei existiert und
gateway.modefehlt, behandelt der Gateway dies als verdächtigen Konfigurationsschaden und verweigert es, für Sie „local zu erraten“. - Binden über Loopback hinaus ohne Authentifizierung wird blockiert (Sicherheitsleitplanke).
SIGUSR1löst einen In-Process-Neustart aus, wenn dies autorisiert ist (commands.restartist standardmäßig aktiviert; setzen Siecommands.restart: false, um manuelle Neustarts zu blockieren, während Anwenden/Aktualisieren per Gateway-Tool/Konfiguration weiterhin erlaubt bleibt).SIGINT-/SIGTERM-Handler stoppen den Gateway-Prozess, stellen aber keinen benutzerdefinierten Terminalzustand wieder her. Wenn Sie die CLI mit einer TUI oder Raw-Mode-Eingabe umschließen, stellen Sie das Terminal vor dem Beenden wieder her.
Optionen
WebSocket-Port (Standardwert stammt aus Konfiguration/Env; üblicherweise
18789).Bindemodus des Listeners.
Überschreibung des Authentifizierungsmodus.
Token-Überschreibung (setzt außerdem
OPENCLAW_GATEWAY_TOKEN für den Prozess).Passwort-Überschreibung.
Gateway-Passwort aus einer Datei lesen.
Den Gateway über Tailscale verfügbar machen.
Tailscale-Serve-/Funnel-Konfiguration beim Herunterfahren zurücksetzen.
Gateway-Start ohne
gateway.mode=local in der Konfiguration erlauben. Umgeht die Startschutzprüfung nur für Ad-hoc-/Dev-Bootstrap; schreibt oder repariert die Konfigurationsdatei nicht.Dev-Konfiguration + Workspace erstellen, falls sie fehlen (überspringt BOOTSTRAP.md).
Dev-Konfiguration + Anmeldedaten + Sitzungen + Workspace zurücksetzen (erfordert
--dev).Vor dem Start jeden vorhandenen Listener auf dem ausgewählten Port beenden.
Ausführliche Logs.
Nur CLI-Backend-Logs in der Konsole anzeigen (und stdout/stderr aktivieren).
WebSocket-Logstil.
Alias für
--ws-log compact.Rohe Modell-Stream-Ereignisse in jsonl protokollieren.
Pfad für Raw-Stream-jsonl.
Gateway neu starten
openclaw gateway restart --safe fordert den laufenden Gateway auf, aktive OpenClaw-Arbeit vor dem Neustart per Preflight zu prüfen. Wenn Vorgänge in der Warteschlange, Antwortzustellung, eingebettete Ausführungen oder Task-Ausführungen aktiv sind, meldet der Gateway die Blocker, fasst doppelte Safe-Restart-Anforderungen zusammen und startet neu, sobald die aktive Arbeit abgearbeitet ist. Ein einfaches restart behält aus Kompatibilitätsgründen das bestehende Service-Manager-Verhalten bei. Verwenden Sie --force nur, wenn Sie ausdrücklich den sofortigen Override-Pfad wünschen.
openclaw gateway restart --safe --skip-deferral führt denselben OpenClaw-bewussten koordinierten Neustart wie --safe aus, umgeht aber die Zurückstellungsprüfung für aktive Arbeit, sodass der Gateway den Neustart sofort ausgibt, auch wenn Blocker gemeldet werden. Verwenden Sie dies als operatorseitigen Notausstieg, wenn eine Zurückstellung durch eine hängengebliebene Task-Ausführung festhängt und --safe allein unbegrenzt warten würde. --skip-deferral erfordert --safe.
Startprofiling
- Setzen Sie
OPENCLAW_GATEWAY_STARTUP_TRACE=1, um Phasen-Timings während des Gateway-Starts zu protokollieren, einschließlicheventLoopMax-Verzögerung pro Phase und Plugin-Lookup-Table-Timings für installed-index, Manifest-Registry, Startplanung und Owner-Map-Arbeit. - Setzen Sie
OPENCLAW_DIAGNOSTICS=timelinemitOPENCLAW_DIAGNOSTICS_TIMELINE_PATH=<path>, um eine Best-Effort-JSONL-Startdiagnose-Timeline für externe QA-Harnesses zu schreiben. Sie können das Flag auch mitdiagnostics.flags: ["timeline"]in der Konfiguration aktivieren; der Pfad wird weiterhin per Env bereitgestellt. Fügen SieOPENCLAW_DIAGNOSTICS_EVENT_LOOP=1hinzu, um Event-Loop-Samples einzuschließen. - Führen Sie
pnpm test:startup:gateway -- --runs 5 --warmup 1aus, um den Gateway-Start zu benchmarken. Der Benchmark zeichnet die erste Prozessausgabe,/healthz,/readyz, Start-Trace-Timings, Event-Loop-Verzögerung und Timingdetails der Plugin-Lookup-Table auf.
Laufenden Gateway abfragen
Alle Abfragebefehle verwenden WebSocket-RPC.- Output modes
- Standard: menschenlesbar (in TTY farbig).
--json: maschinenlesbares JSON (ohne Styling/Spinner).--no-color(oderNO_COLOR=1): ANSI deaktivieren, während das menschenlesbare Layout erhalten bleibt.
Wenn Sie
--url setzen, fällt die CLI nicht auf Konfigurations- oder Umgebungsanmeldedaten zurück. Übergeben Sie --token oder --password explizit. Fehlende explizite Anmeldedaten sind ein Fehler.gateway health
/healthz ist eine Liveness-Probe: Er antwortet, sobald der Server HTTP beantworten kann. Der HTTP-Endpunkt /readyz ist strenger und bleibt rot, während Start-Plugin-Sidecars, Kanäle oder konfigurierte Hooks noch stabilisieren. Lokale oder authentifizierte detaillierte Bereitschaftsantworten enthalten einen eventLoop-Diagnoseblock mit Event-Loop-Verzögerung, Event-Loop-Auslastung, CPU-Core-Verhältnis und einem degraded-Flag.
gateway usage-cost
Nutzungs- und Kostenzusammenfassungen aus Sitzungslogs abrufen.
Anzahl der einzuschließenden Tage.
gateway stability
Den aktuellen Diagnose-Stabilitätsrecorder von einem laufenden Gateway abrufen.
Maximale Anzahl einzuschließender aktueller Ereignisse (max.
1000).Nach Diagnoseereignistyp filtern, etwa
payload.large oder diagnostic.memory.pressure.Nur Ereignisse nach einer Diagnosesequenznummer einschließen.
Ein persistiertes Stabilitätsbundle lesen, statt den laufenden Gateway aufzurufen. Verwenden Sie
--bundle latest (oder nur --bundle) für das neueste Bundle unter dem Zustandsverzeichnis, oder übergeben Sie direkt einen Bundle-JSON-Pfad.Eine teilbare ZIP-Datei mit Supportdiagnosen schreiben, statt Stabilitätsdetails auszugeben.
Ausgabepfad für
--export.Privacy and bundle behavior
Privacy and bundle behavior
- Datensätze behalten operative Metadaten: Ereignisnamen, Zählwerte, Bytegrößen, Speicherwerte, Warteschlangen-/Sitzungszustand, Kanal-/Plugin-Namen und redigierte Sitzungszusammenfassungen. Sie behalten keinen Chattext, keine Webhook-Bodys, keine Tool-Ausgaben, keine rohen Anfrage- oder Antwortbodys, Tokens, Cookies, geheimen Werte, Hostnamen oder rohen Sitzungs-IDs. Setzen Sie
diagnostics.enabled: false, um den Recorder vollständig zu deaktivieren. - Bei fatalen Gateway-Beendigungen, Shutdown-Timeouts und Startfehlern nach Neustarts schreibt OpenClaw denselben Diagnose-Snapshot nach
~/.openclaw/logs/stability/openclaw-stability-*.json, wenn der Recorder Ereignisse hat. Prüfen Sie das neueste Bundle mitopenclaw gateway stability --bundle latest;--limit,--typeund--since-seqgelten ebenfalls für Bundle-Ausgaben.
gateway diagnostics export
Eine lokale Diagnose-ZIP-Datei schreiben, die zum Anhängen an Fehlerberichte vorgesehen ist. Informationen zum Datenschutzmodell und zu Bundle-Inhalten finden Sie unter Diagnostics Export.
Ausgabe-ZIP-Pfad. Standardmäßig ein Supportexport unter dem Zustandsverzeichnis.
Maximale Anzahl bereinigter Logzeilen, die eingeschlossen werden.
Maximale Anzahl von Logbytes, die geprüft werden.
Gateway-WebSocket-URL für den Health-Snapshot.
Gateway-Token für den Health-Snapshot.
Gateway-Passwort für den Health-Snapshot.
Timeout für Status-/Health-Snapshot.
Suche nach persistiertem Stabilitätsbundle überspringen.
Den geschriebenen Pfad, die Größe und das Manifest als JSON ausgeben.
gateway status
gateway status zeigt den Gateway-Dienst (launchd/systemd/schtasks) sowie optional eine Probe der Konnektivitäts-/Authentifizierungsfähigkeit.
Fügt ein explizites Prüfziel hinzu. Konfigurierte Remote-Ziele + localhost werden weiterhin geprüft.
Token-Authentifizierung für die Prüfung.
Passwortauthentifizierung für die Prüfung.
Zeitlimit für die Prüfung.
Überspringt die Konnektivitätsprüfung (nur Service-Ansicht).
Scannt auch systemweite Services.
Erweitert die standardmäßige Konnektivitätsprüfung zu einer Leseprüfung und beendet den Prozess mit einem Nicht-Null-Code, wenn diese Leseprüfung fehlschlägt. Kann nicht mit
--no-probe kombiniert werden.Statussemantik
Statussemantik
gateway statusbleibt für Diagnosen verfügbar, selbst wenn die lokale CLI-Konfiguration fehlt oder ungültig ist.- Das standardmäßige
gateway statusweist den Service-Zustand, die WebSocket-Verbindung und die zum Handshake-Zeitpunkt sichtbare Authentifizierungsfähigkeit nach. Es weist keine Lese-/Schreib-/Admin-Operationen nach. - Diagnoseprüfungen verändern bei der erstmaligen Geräteauthentifizierung nichts: Sie verwenden ein vorhandenes zwischengespeichertes Geräte-Token wieder, falls eines vorhanden ist, erstellen aber keine neue CLI-Geräteidentität oder schreibgeschützten Gerätekopplungsdatensatz nur zur Statusprüfung.
gateway statuslöst konfigurierte Authentifizierungs-SecretRefs für die Prüf-Authentifizierung auf, wenn möglich.- Wenn ein erforderlicher Authentifizierungs-SecretRef in diesem Befehlspfad nicht aufgelöst wird, meldet
gateway status --jsonrpc.authWarning, wenn Prüfkonnektivität/Authentifizierung fehlschlägt; übergeben Sie--token/--passwordexplizit oder lösen Sie zuerst die Secret-Quelle auf. - Wenn die Prüfung erfolgreich ist, werden Warnungen zu nicht aufgelösten Authentifizierungsreferenzen unterdrückt, um falsch positive Meldungen zu vermeiden.
- Verwenden Sie
--require-rpcin Skripten und Automatisierung, wenn ein lauschender Service nicht ausreicht und auch RPC-Aufrufe mit Leseumfang fehlerfrei sein müssen. --deepfügt einen Best-Effort-Scan nach zusätzlichen launchd-/systemd-/schtasks-Installationen hinzu. Wenn mehrere Gateway-ähnliche Services erkannt werden, gibt die Ausgabe für Menschen Bereinigungshinweise aus und warnt, dass die meisten Setups ein Gateway pro Maschine ausführen sollten.--deepmeldet außerdem eine kürzliche Übergabe eines Gateway-Supervisor-Neustarts, wenn der Service-Prozess für einen externen Supervisor-Neustart sauber beendet wurde.--deepführt die Konfigurationsvalidierung im Plugin-fähigen Modus (pluginValidation: "full") aus und zeigt konfigurierte Plugin-Manifestwarnungen an (zum Beispiel fehlende Metadaten zur Kanalkonfiguration), damit Installations- und Update-Smoke-Checks sie erkennen. Das standardmäßigegateway statusbehält den schnellen schreibgeschützten Pfad bei, der die Plugin-Validierung überspringt.- Die Ausgabe für Menschen enthält den aufgelösten Dateilogpfad sowie eine Momentaufnahme der CLI-gegenüber-Service-Konfigurationspfade/-Gültigkeit, um Profil- oder Zustandsverzeichnisdrift zu diagnostizieren.
Linux-systemd-Prüfungen auf Authentifizierungsdrift
Linux-systemd-Prüfungen auf Authentifizierungsdrift
- Bei Linux-systemd-Installationen lesen Prüfungen auf Service-Authentifizierungsdrift sowohl
Environment=- als auchEnvironmentFile=-Werte aus der Unit (einschließlich%h, zitierter Pfade, mehrerer Dateien und optionaler--Dateien). - Driftprüfungen lösen
gateway.auth.token-SecretRefs mit der zusammengeführten Laufzeitumgebung auf (zuerst Service-Befehlsumgebung, dann Prozessumgebung als Fallback). - Wenn Token-Authentifizierung nicht effektiv aktiv ist (expliziter
gateway.auth.modevonpassword/none/trusted-proxyoder nicht gesetzter Modus, bei dem das Passwort gewinnen kann und kein Token-Kandidat gewinnen kann), überspringen Token-Driftprüfungen die Auflösung des Konfigurationstokens.
gateway probe
gateway probe ist der Befehl zum „Alles debuggen“. Er prüft immer:
- Ihr konfiguriertes Remote-Gateway (falls gesetzt) und
- localhost (local loopback), selbst wenn ein Remote-Ziel konfiguriert ist.
--url übergeben, wird dieses explizite Ziel vor beiden hinzugefügt. Die Ausgabe für Menschen kennzeichnet die Ziele als:
URL (explicit)Remote (configured)oderRemote (configured, inactive)Local loopback
Wenn mehrere Gateways erreichbar sind, gibt der Befehl alle aus. Mehrere Gateways werden unterstützt, wenn Sie isolierte Profile/Ports verwenden (z. B. einen Rettungs-Bot), aber die meisten Installationen führen weiterhin ein einzelnes Gateway aus.
Interpretation
Interpretation
Reachable: yesbedeutet, dass mindestens ein Ziel eine WebSocket-Verbindung akzeptiert hat.Capability: read-only|write-capable|admin-capable|pairing-pending|connect-onlymeldet, was die Prüfung über die Authentifizierung nachweisen konnte. Dies ist von der Erreichbarkeit getrennt.Read probe: okbedeutet, dass auch Detail-RPC-Aufrufe mit Leseumfang (health/status/system-presence/config.get) erfolgreich waren.Read probe: limited - missing scope: operator.readbedeutet, dass die Verbindung erfolgreich war, RPC mit Leseumfang aber eingeschränkt ist. Dies wird als eingeschränkte Erreichbarkeit gemeldet, nicht als vollständiger Fehler.Read probe: failednachConnect: okbedeutet, dass das Gateway die WebSocket-Verbindung akzeptiert hat, nachfolgende Lesediagnosen aber wegen Zeitüberschreitung oder Fehlern scheiterten. Auch dies ist eingeschränkte Erreichbarkeit, kein unerreichbares Gateway.- Wie
gateway statusverwendet probe vorhandene zwischengespeicherte Geräteauthentifizierung wieder, erstellt aber keine erstmalige Geräteidentität oder keinen Kopplungszustand. - Der Exit-Code ist nur dann ungleich null, wenn kein geprüftes Ziel erreichbar ist.
JSON-Ausgabe
JSON-Ausgabe
Oberste Ebene:
ok: Mindestens ein Ziel ist erreichbar.degraded: Mindestens ein Ziel hat eine Verbindung akzeptiert, aber die vollständige Detail-RPC-Diagnose nicht abgeschlossen.capability: Beste Fähigkeit, die über erreichbare Ziele hinweg gesehen wurde (read_only,write_capable,admin_capable,pairing_pending,connected_no_operator_scopeoderunknown).primaryTargetId: Bestes Ziel, das in dieser Reihenfolge als aktiver Gewinner behandelt werden soll: explizite URL, SSH-Tunnel, konfiguriertes Remote-Ziel, dann local loopback.warnings[]: Best-Effort-Warndatensätze mitcode,messageund optionalentargetIds.network: Hinweise auf local loopback-/Tailnet-URLs, abgeleitet aus aktueller Konfiguration und Host-Netzwerk.discovery.timeoutMsunddiscovery.count: Das tatsächlich für diesen Prüfdurchlauf verwendete Discovery-Budget bzw. die Ergebnisanzahl.
targets[].connect):ok: Erreichbarkeit nach Verbindung + Einstufung als eingeschränkt.rpcOk: Vollständiger Detail-RPC-Erfolg.scopeLimited: Detail-RPC ist wegen fehlendem Operator-Umfang fehlgeschlagen.
targets[].auth):role: Inhello-okgemeldete Authentifizierungsrolle, wenn verfügbar.scopes: Inhello-okgemeldete gewährte Umfänge, wenn verfügbar.capability: Die angezeigte Klassifizierung der Authentifizierungsfähigkeit für dieses Ziel.
Häufige Warncodes
Häufige Warncodes
ssh_tunnel_failed: Einrichtung des SSH-Tunnels fehlgeschlagen; der Befehl ist auf direkte Prüfungen zurückgefallen.multiple_gateways: Mehr als ein Ziel war erreichbar; dies ist ungewöhnlich, sofern Sie nicht absichtlich isolierte Profile ausführen, etwa einen Rettungs-Bot.auth_secretref_unresolved: Ein konfigurierter Authentifizierungs-SecretRef konnte für ein fehlgeschlagenes Ziel nicht aufgelöst werden.probe_scope_limited: WebSocket-Verbindung erfolgreich, aber die Leseprüfung wurde durch fehlendesoperator.readeingeschränkt.
Remote über SSH (Parität mit der Mac-App)
Der macOS-App-Modus „Remote over SSH“ verwendet eine lokale Portweiterleitung, sodass das Remote-Gateway (das möglicherweise nur an local loopback gebunden ist) unterws://127.0.0.1:<port> erreichbar wird.
CLI-Entsprechung:
user@host oder user@host:port (Port ist standardmäßig 22).Identitätsdatei.
Wählt den ersten erkannten Gateway-Host als SSH-Ziel aus dem aufgelösten Discovery-Endpunkt (
local. plus konfigurierte Wide-Area-Domain, falls vorhanden). Nur-TXT-Hinweise werden ignoriert.gateway.remote.sshTargetgateway.remote.sshIdentity
gateway call <method>
Low-Level-RPC-Helfer.
JSON-Objektzeichenfolge für Parameter.
Gateway-WebSocket-URL.
Gateway-Token.
Gateway-Passwort.
Zeitlimitbudget.
Hauptsächlich für agentenartige RPCs, die Zwischenereignisse vor einer finalen Nutzlast streamen.
Maschinenlesbare JSON-Ausgabe.
--params muss gültiges JSON sein.Gateway-Service verwalten
Mit einem Wrapper installieren
Verwenden Sie--wrapper, wenn der verwaltete Service über ein anderes ausführbares Programm gestartet werden muss, zum Beispiel ein
Secrets-Manager-Shim oder ein Run-as-Helfer. Der Wrapper erhält die normalen Gateway-Argumente und ist
dafür verantwortlich, schließlich openclaw oder Node mit diesen Argumenten per exec auszuführen.
gateway install validiert, dass der Pfad eine
ausführbare Datei ist, schreibt den Wrapper in die Service-ProgramArguments und persistiert
OPENCLAW_WRAPPER in der Service-Umgebung für spätere erzwungene Neuinstallationen, Updates und doctor-
Reparaturen.
OPENCLAW_WRAPPER während der Neuinstallation:
Befehlsoptionen
Befehlsoptionen
gateway status:--url,--token,--password,--timeout,--no-probe,--require-rpc,--deep,--jsongateway install:--port,--runtime <node|bun>,--token,--wrapper <path>,--force,--jsongateway restart:--safe,--skip-deferral,--force,--wait <duration>,--jsongateway uninstall|start:--jsongateway stop:--disable,--json
Lifecycle-Verhalten
Lifecycle-Verhalten
- Verwenden Sie
gateway restart, um einen verwalteten Dienst neu zu starten. Verketten Siegateway stopundgateway startnicht als Ersatz für einen Neustart. - Unter macOS verwendet
gateway stopstandardmäßiglaunchctl bootout, wodurch der LaunchAgent aus der aktuellen Boot-Sitzung entfernt wird, ohne eine Deaktivierung dauerhaft zu speichern — die automatische KeepAlive-Wiederherstellung bleibt für zukünftige Abstürze aktiv undgateway startaktiviert sauber erneut, ohne ein manuelleslaunchctl enable. Übergeben Sie--disable, um KeepAlive und RunAtLoad dauerhaft zu unterdrücken, damit der Gateway bis zum nächsten explizitengateway startnicht neu startet; verwenden Sie dies, wenn ein manueller Stopp Neustarts oder Systemneustarts überdauern soll. gateway restart --safeweist den laufenden Gateway an, aktive OpenClaw-Arbeit vorab zu prüfen und den Neustart aufzuschieben, bis Antwortzustellung, eingebettete Runs und Task-Runs abgearbeitet sind.--safekann nicht mit--forceoder--waitkombiniert werden.gateway restart --wait 30süberschreibt das konfigurierte Drain-Budget für diesen Neustart. Zahlen ohne Einheit sind Millisekunden; Einheiten wies,mundhwerden akzeptiert.--wait 0wartet unbegrenzt.gateway restart --safe --skip-deferralführt den OpenClaw-bewussten sicheren Neustart aus, umgeht aber das Aufschub-Gate, sodass der Gateway den Neustart sofort auslöst, auch wenn Blocker gemeldet werden. Operator-Notausstieg für Aufschübe durch hängende Task-Runs; erfordert--safe.gateway restart --forceüberspringt das Drain aktiver Arbeit und startet sofort neu. Verwenden Sie dies, wenn ein Operator die aufgeführten Task-Blocker bereits geprüft hat und den Gateway jetzt zurückhaben möchte.- Lifecycle-Befehle akzeptieren
--jsonfür Skripting.
Authentifizierung und SecretRefs zum Installationszeitpunkt
Authentifizierung und SecretRefs zum Installationszeitpunkt
- Wenn Token-Authentifizierung ein Token erfordert und
gateway.auth.tokenvon SecretRef verwaltet wird, validiertgateway install, dass die SecretRef auflösbar ist, speichert das aufgelöste Token jedoch nicht dauerhaft in Dienstumgebungs-Metadaten. - Wenn Token-Authentifizierung ein Token erfordert und die konfigurierte Token-SecretRef nicht aufgelöst ist, schlägt die Installation geschlossen fehl, statt Fallback-Klartext dauerhaft zu speichern.
- Für Passwortauthentifizierung bei
gateway runbevorzugen SieOPENCLAW_GATEWAY_PASSWORD,--password-fileoder ein SecretRef-gestütztesgateway.auth.passwordgegenüber inline--password. - Im abgeleiteten Authentifizierungsmodus lockert ein nur in der Shell gesetztes
OPENCLAW_GATEWAY_PASSWORDdie Token-Anforderungen für die Installation nicht; verwenden Sie dauerhafte Konfiguration (gateway.auth.passwordoder Konfigurationenv), wenn Sie einen verwalteten Dienst installieren. - Wenn sowohl
gateway.auth.tokenals auchgateway.auth.passwordkonfiguriert sind undgateway.auth.modenicht gesetzt ist, wird die Installation blockiert, bis der Modus explizit gesetzt ist.
Gateways ermitteln (Bonjour)
gateway discover sucht nach Gateway-Beacons (_openclaw-gw._tcp).
- Multicast DNS-SD:
local. - Unicast DNS-SD (Wide-Area Bonjour): Wählen Sie eine Domain (Beispiel:
openclaw.internal.) und richten Sie Split-DNS + einen DNS-Server ein; siehe Bonjour.
role(Hinweis zur Gateway-Rolle)transport(Transporthinweis, z. B.gateway)gatewayPort(WebSocket-Port, üblicherweise18789)sshPort(nur vollständiger Ermittlungsmodus; Clients verwenden standardmäßig SSH-Ziele auf22, wenn er fehlt)tailnetDns(MagicDNS-Hostname, wenn verfügbar)gatewayTls/gatewayTlsSha256(TLS aktiviert + Zertifikat-Fingerabdruck)cliPath(nur vollständiger Ermittlungsmodus)
gateway discover
Timeout pro Befehl (Browse/Resolve).
Maschinenlesbare Ausgabe (deaktiviert auch Styling/Spinner).
- Die CLI durchsucht
local.plus die konfigurierte Wide-Area-Domain, wenn eine aktiviert ist. wsUrlin der JSON-Ausgabe wird aus dem aufgelösten Dienstendpunkt abgeleitet, nicht aus reinen TXT-Hinweisen wielanHostodertailnetDns.- Bei
local.mDNS und Wide-Area DNS-SD werdensshPortundcliPathnur veröffentlicht, wenndiscovery.mdns.modeauffullgesetzt ist.