Node-Verbindung

Node Verbindung

Ziel: Einen genauen Client gegen ein bestimmtes Gateway reparieren und dann die frische Verbindung dieses Clients nachweisen.

1. Ziel festlegen

Die Zielumgebung/das Profil, die OpenClaw-Binärdatei, das Konfigurations-/Statusverzeichnis, die Gateway-URL/den Port und den Dienst aufzeichnen, bevor etwas geändert wird.

• Für jeden Befehl zu Konfiguration, Log, Dienst, Gerät und Node den benannten Deployment-Wrapper/das Profil verwenden.
• Niemals zu einem reinen openclaw, einer Testumgebung oder einem ähnlich benannten Deployment abweichen.
• Wenn die globale ausführbare Datei veraltet ist, das Ziel über seinen Besitzer aufrufen.
• Überprüfen, ob Status, Konfiguration, Logs und Prozessidentität dasselbe Gateway beschreiben.

Das Ziel-Gateway identifizieren, bevor Pairing oder Authentifizierung geändert werden.

2. Client klassifizieren

Vor der Auswahl von Befehlen aus der Anfrage und dem Gateway-Log klassifizieren:

• Control UI Browser: Der Benutzer sagt Browser, Dashboard, Control UI oder Webchat; Logs zeigen client=openclaw-control-ui oder mode=webchat.
• Native mobile/Node: Die offizielle App zeigt Verbinden, QR scannen oder Setup-Code; Logs/Anfragemetadaten zeigen einen nativen Client oder role=node.

Ein Telefon kann einer der beiden Client-Typen sein. Für einen Telefon-Browser nicht openclaw qr oder openclaw nodes status verwenden; diese gehören zum nativen mobilen/Node-Pairing.

3. Fehlgeschlagenen Versuch beobachten

Diese Befehle über das festgelegte Ziel ausführen:

openclaw gateway status --deep
openclaw logs --follow --json
openclaw devices list
openclaw config get gateway.mode
openclaw config get gateway.bind
openclaw config get gateway.remote.url
openclaw config get gateway.auth.mode
openclaw config get gateway.auth.allowTailscale
openclaw config get gateway.tailscale.mode

Den Client einmal erneut versuchen lassen, während die Logs live sind. Seine Client-ID, den Modus, die Plattform, die Adresse, das Authentifizierungsergebnis, die Geräte-ID, den Benutzer und den Schließcode korrelieren. Andere gepaarte Geräte ignorieren.

Den ersten fehlgeschlagenen Übergang interpretieren:

• Kein passender Gateway-Versuch: Route-, DNS-, TLS-, Origin- oder Proxy-Problem.
• token_missing, password_missing, Nichtübereinstimmung oder Fehler der Tailscale-Identität: Authentifizierung fehlgeschlagen vor dem Pairing, daher ist eine leere ausstehende Liste zu erwarten.
• pairing required: Route und Authentifizierung erfolgreich; die genaue ausstehende Anfrage genehmigen.
• client connected: conn, client, mode und role dem genauen Client zuordnen. Der Eintritt erfolgt vor der Hello-Antwort; wenn 1006 folgt, Authentifizierung/Pairing beibehalten und Hello-Zustellung, Lebenszyklus, Transport, Proxy oder Wiederverbindung untersuchen. Ältere Builds verwenden überlappende authenticated user connected-/webchat connected-Datensätze, die flüchtige Clients auslassen.
• 1006 ohne passenden Anwendungs-Eintrittsdatensatz beweist keine Authentifizierung/Pairing; den früheren Handshake-Übergang untersuchen.

4. Route nachweisen

Eine Topologie wählen: gleicher Rechner, LAN, Tailnet oder öffentlicher Reverse Proxy. Nicht mischen.

• Browser Control UI benötigt HTTPS oder Localhost für die Browser-Geräteidentität. Eine entfernte reine HTTP-Tailnet-/LAN-URL ist kein gültiger Ersatz.
• gateway.tailscale.mode=off bedeutet, dass OpenClaw Serve/Funnel nicht verwaltet. Es beweist nicht, dass Tailscale oder eine extern verwaltete Serve-Route abwesend ist.
• Wenn Tailscale beteiligt ist, den Live-Zustand untersuchen, anstatt ihn aus der OpenClaw-Konfiguration abzuleiten:

tailscale status --json
tailscale serve status --json

Die URL des Clients mit dem Listener/Proxy-Route abgleichen, die das festgelegte Gateway erreicht.

5A. Control UI Browser-Spur

Browser-Authentifizierung wiederherstellen, bevor nach einer Pairing-Anfrage gesucht wird:

• Bei Token-/Passwort-Authentifizierung die Anmeldedaten in den Control UI-Einstellungen eingeben. Niemals permanente Geheimnisse in Chat, Logs oder URLs ablegen.
• openclaw dashboard auf dem Gateway-Host für eine einmalige signierte Übergabe bevorzugen. --no-open nur verwenden, wenn der Bediener die Zwischenablage dieses Hosts abrufen kann, und die Host-Zwischenablage/den Browser außerhalb der Agent-Tools halten. Niemals dashboard --json erfassen: es kann die Übergabe und gemeinsame Anmeldedaten offenlegen. Niemals eine Loopback-Übergabe-URL an ein entferntes Telefon weiterleiten, umschreiben oder senden.
• Für Tailscale Serve die Live-Route und die weitergeleitete Identität überprüfen. gateway.auth.allowTailscale nur für diese beabsichtigte Vertrauensgrenze aktivieren. Verifizierte Tailscale Control UI-Authentifizierung mit Browser-Geräteidentität kann das Pairing überspringen.

Nach erfolgreicher Authentifizierung:

• Erneut versuchen; niemals das Pairing aus dem Vor-Authentifizierungsversuch ableiten. Token-/Passwort-Authentifizierung kann pairing required offenbaren; verifizierte Tailscale-Identität kann es überspringen.
• Wenn Logs pairing required sagen, Geräte neu auflisten und die genaue Anfrage-ID genehmigen.
• Eine erfolgreiche verifizierte Tailscale-Verbindung kann korrekt keine ausstehende oder gepaarte Gerätezeile erstellen.
• Nach einem wiederholten 1006, Authentifizierung/Pairing beibehalten und Wiederverbindungsbelege untersuchen.

5B. Native mobile/Node-Spur

Die native Route durch das festgelegte Ziel inspizieren, ohne die Setup-Anmeldedaten offenzulegen:

openclaw qr --json | jq '{gatewayUrl, gatewayUrls, auth, access, accessDowngraded, urlSource}'

Für eine CLI, die ein entferntes Gateway steuert, --remote vor --json hinzufügen; es wählt gateway.remote.url und entfernte Anmeldedaten aus. Wenn der Redaktionsfilter nicht verfügbar ist, rohes QR-JSON nicht in für Agenten sichtbarer Ausgabe ausführen.

gatewayUrl und urlSource überprüfen. Der Setup-Code ist passwortäquivalent: Den Bediener ihn aus Control UI → Geräte → Gerät paaren kopieren lassen, oder openclaw qr --setup-code-only in einem Terminal außerhalb der Agent-Tools ausführen und direkt in die offizielle App einfügen. Niemals über Agent/Chat/Tool-Ausgabe weiterleiten. Nach einer URL-/Authentifizierungsbehebung oder Ablauf einen neuen Code generieren.

Wenn die App pairing required meldet:

openclaw devices list
openclaw devices approve --latest   # nur Vorschau; beendet ohne Genehmigung
openclaw devices approve <requestId>
openclaw nodes status

--latest zeigt nur die aktuelle Anfrage als Vorschau; niemals als Genehmigung behandeln. Unmittelbar vor dem Befehl mit der genauen ID neu auflisten, da Wiederholungen die Anfrage überschreiben können. Niemals nach Position, Alter oder Ähnlichkeit genehmigen.

6. Korrelieren und abschließen

Vor der Genehmigung verfügbare Fakten zu Anfrage, Gerät/öffentlichem Schlüssel, Client, Modus/Rolle, Plattform, Adresse, Benutzer und Wiederholungszeit abgleichen.

Erfolg nur dann erklären, wenn ein neuer Versuch nach der letzten Änderung alle zutreffenden Prüfungen nachweist:

• der genaue Client erreicht das festgelegte Gateway;
• die beabsichtigte Authentifizierung erfolgreich ist;
• der Browser die ersten Anfragen abschließt oder der native Node in openclaw nodes status erscheint;
• die Genehmigung die genaue Anfrage-ID verwendet hat; und
• kein sofortiger Authentifizierungs-, Pairing- oder Wiederverbindungsfehler folgt.

Ein QR/Setup-Code, ein gestarteter Browser, eine leere ausstehende Liste, eine Genehmigung, eine Anzahl gepaarter Geräte oder ein Tailscale-Ping beweist nur einen Übergang.

Die Diagnose, die gewählte Route/Authentifizierungsspur, die Beweise für den genauen Client und alle verbleibenden fehlgeschlagenen Übergänge melden.