OpenClaw 2026: iOS/Android-Knoten auf einem Fern-Mac M4 in Kanada koppeln — gateway.mode remote, wss/Tailscale-Sicherheitseingang, transpazifische SSH-Tunnel und openclaw doctor-Tickets (Schrittkatalog + Vergleichstabellen + FAQ)

Wenn Ihr OpenClaw-Gateway ausschließlich auf einem gemieteten Mac mini M4 in Kanada läuft und Kolleginnen in APAC iPhones, iPads oder Android-Geräte als Knoten (role: node) anbinden wollen, entscheidet nicht die App-Installation — sondern ob das Telefon einen konformen wss://-Endpunkt auf einem dauerhaft erreichbaren Host erreicht und ob Betrieb gateway.mode: "remote" mit CLI-Freigaben (nodes approve) abstimmt. Diese Seite ist ein Gateway-zentriertes Knoten-Pairing-Runbook für 2026. Für macOS-Menüleisten-Clients, Dashboard-Lesezeichen und 18789 über SSH/Tailnet lesen Sie OpenClaw 2026: Nur-Gateway in Kanada auf Fern-Mac M4 — macOS-Clients per SSH und Tailnet, Dashboard, TCP 18789, transpazifische Tokens, Loopback und LaunchAgent — jener Artikel verdrahtet Operatoren; hier verdrahten Sie Telefone. Ist das Gateway noch nicht installiert, zuerst OpenClaw 2026: Fern-Mac installieren, ausrollen & Fehleranalyse — openclaw onboard, Gateway-Daemon und praktische M4-Ressourcenplanung in Kanada abschließen.

Warum ein Kanada-M4 das einzige Gateway für mobile Knoten sein sollte

Im OpenClaw-Remote-Modell sollte pro Host genau ein Gateway-Prozess laufen, sofern Sie Profile nicht bewusst isolieren. Das Gateway besitzt Sessions, Channels, Auth und Agent-Zustand; iOS/Android-Apps hosten kein Gateway — sie verbinden sich als periphere Knoten über die Gateway-WebSocket-Schnittstelle und tauschen node.*-RPC aus. Ein gemieteter Mac mini M4 in Kanada passt zur Rolle „immer online“: Laptops schlafen, Telegram/Slack-Channels und Pairing-Warteschlangen sollten es nicht. Telefone liefern Kamera, Sensoren oder Feldaktionen; der M4 liefert Kontinuität.

Der typische Fehler transpazifischer Teams: ein zweites Gateway auf einem APAC-Laptop, das Tokens spaltet, Pairing-Anfragen auf dem falschen Host verfallen lässt und openclaw nodes pending leer wirken lässt, während das Telefon dreht. Die Abhilfe: ein Kanada-Gateway + alle CLI und Knoten auf remote, APAC-Mitarbeitende verwalten den Host per SSH oder Tailnet statt lokal ein weiteres Gateway zu starten.

Gateway-owned Pairing 2026 (was sich geändert hat)

Seit dem Modell gateway-owned pairing ist das Gateway die Quelle der Wahrheit, welche Knoten beitreten dürfen. Ablauf: Knoten verbindet per WebSocket → Gateway speichert pending und emittiert node.pair.requested → Operator führt openclaw nodes approve <requestId> aus (oder UI-Äquivalent) → Gateway stellt Token aus → Knoten verbindet erneut als gekoppelt. Pending-Einträge verfallen nach fünf Minuten; QR oder Setup-Codes neu erzeugen statt veraltete Anfragen zu verfolgen.

Ab 2026.3.31 bleiben Knotenbefehle deaktiviert, bis node pairing freigegeben ist — Device-Pairing allein reicht nicht, um deklarierte Knotenbefehle freizuschalten. openclaw devices approve und openclaw nodes approve sind verwandt, aber getrennte Tore: Telefone können in Device-Listen erscheinen, während Knoten-RPC weiter 1008: pairing required liefert, bis der Knoten-Store „approved“ zeigt. Bleibt openclaw nodes pending nach dem Scan leer, auf einen Build upgraden, der WebSocket-Pairing-State in den Knoten-Store schreibt (Fixes ab 2026.2.28 sind upstream dokumentiert), bevor Sie ein Netzwerk-Ticket öffnen.

Protokollseitig nutzen Operatoren node.pair.list, node.pair.approve und node.pair.reject über die CLI-Wrapper; UIs sind dünne Clients derselben Gateway-Wahrheit. Für Audits zählt das Pairing-Log auf dem Kanada-Host, nicht das zuletzt geöffnete Laptop mit der Mobile-App.

gateway.mode remote und Credential-Priorität

Auf dem Kanada-Host sollte das Gateway auf 127.0.0.1:18789 lauschen (Build-Default prüfen; ein Port fürs Team dokumentieren). Auf APAC-Operator-Laptops setzen Sie gateway.mode: "remote", damit openclaw health, openclaw nodes pending und Approve-Befehle Kanada über SSH oder Tailscale treffen, nicht einen leeren lokalen Port.

Offizielle Remote-Hinweise: Ist das Gateway nur auf Loopback gebunden, bleibt gateway.remote.url als ws://127.0.0.1:18789 und Sie stellen SSH-Local-Forwarding vor der CLI her. Für Tailnet-Direct: transport: "direct" mit privater ws://- oder wss://-URL. Kritische Regel: --url übernimmt nicht implizit das Config-Token — bei URL-Override --token oder --password explizit mitgeben.

{
  gateway: {
    mode: "remote",
    remote: {
      url: "ws://127.0.0.1:18789",
      token: "<gateway-token>",
      sshTarget: "ca-m4-gateway",
    },
  },
}

{
  gateway: {
    mode: "remote",
    remote: {
      transport: "direct",
      url: "wss://ca-m4.ihr-tailnet.ts.net",
      token: "<gateway-token>",
    },
  },
}

Pairing-Runbook: von Loopback-grün bis nodes approve

Voraussetzung: Gateway wird per launchd auf dem Kanada-M4 verwaltet. Zeigen Schritte unten Fehler, Telefone nicht auf öffentliches Klartext-ws:// zeigen.

Schritt 1 — Loopback-Health auf dem Gateway-Host

Per SSH auf den Kanada-Mac und Listen + Health prüfen:

curl -fsS "http://127.0.0.1:18789/health" && echo OK
lsof -nP -iTCP:18789 -sTCP:LISTEN

Schritt 2 — Sicherer WebSocket-Eingang für Telefone

Für netzübergreifendes Mobile-Pairing schlagen iOS/Android bei Klartext-ws:// fehl. Echtes TLS als wss://<magicdns> per Tailscale Serve (bevorzugt bei Loopback-Gateway) oder Enterprise-Reverse-Proxy mit vertrauenswürdiger Kette. Büro-LAN-Debug darf ws:// nutzen; transpazifische Telefone im öffentlichen Internet nicht.

Schritt 3 — QR / Setup-Code und node pending

Auf dem Host (oder Laptop mit aktivem Tunnel):

openclaw qr
openclaw qr --remote
openclaw nodes pending
openclaw nodes approve <requestId>
openclaw nodes status

Nach dem Scan die Pending-Zeile bestätigen, dann freigeben. Freigaben an Ticket-IDs in On-Call-Docs binden, damit Nacht-Contractors keine unbekannten Fingerprints approven.

Schritt 4 — Knoten-RPC-Rauchtest

Minimalen node.*-Aufruf von Gateway-Seite auslösen (oder Channel-Workflow mit Knoten-Tools). Hoher Pazifik-RTT allein ist kein Fehler; häufige Disconnects deuten auf Tailnet-Pfad, MTU oder Telefon-Energiesparen — nicht zwingend App-Neuinstallation.

Entscheidungsmatrix Sicherheitseingang (Telefone vs. Operatoren)

Telefone haben keinen SSH-Tunnel; Operatoren oft schon. Pfade in Runbooks getrennt halten.

Transpazifischer SSH: Knoten freigeben, wenn Telefone noch nicht im Tailnet sind

Contractor-Telefone ohne Tailscale brauchen trotzdem einen wss://-Endpunkt (Serve oder Firmen-Proxy). SSH hilft Operatoren, nach Tunneling auf Loopback zu approven — er ersetzt nicht den TLS-Pfad des Handys.

ssh -N -L 18789:127.0.0.1:18789 user@ca-m4-host
# Neues Terminal: Remote-Config zeigt auf ws://127.0.0.1:18789
openclaw health --token "<gateway-token>"
openclaw nodes pending
openclaw nodes approve <requestId>

Für 24/7-Tunnel ssh -N im LaunchAgent auf dem Operator-Mac persistieren und gateway.remote.token in der Config halten, nicht in Shell-Profilen. Der Kanada-Host lässt das Gateway nur auf Loopback.

M4-Kapazität: ein Gateway, viele Telefon-Knoten

Ein 24 GB / 512 GB Kanada-M4 trägt ein Gateway plus mehrere gekoppelte Knoten, wenn Channels und Workspace-Snapshots begrenzt sind. 1 TB / 2 TB, wenn Log-Retention, Channel-Medien und Workspace-Exports um APFS-Kapazität konkurrieren. Ein zweiter gemieteter M4 lohnt bei isolierten Gateway-Profilen (Prod vs. Staging-Knoten), nicht weil drei Telefone einen Apple-Silicon-Host zwingend überlasten — Telefone teilen Sessions und Quotas, sie spawnen keinen zweiten Gateway-Prozess.

Jedes freigegebene Gerät im CMDB taggen; Pairing ohne Ownership wird über Zeitzonen nicht auditierbar. Für Disk- und Parallel-Mathe bei wachsenden Channels: OpenClaw 2026 Kanada M4: Produktions-Knoten-Disk, Channel-Erneuerung & Gateway-HowTo-FAQ. Vor größeren Upgrades des Gateway-Builds empfiehlt sich das Stabilitäts-Runbook OpenClaw 2026: Kontrolliertes Upgrade und stabiler Betrieb auf einem Fern-Mac M4 in Kanada.

openclaw doctor: Ticket-Playbook

openclaw doctor (und --lint / --deep wenn verfügbar) als ein Snapshot ins Ticket: auf dem Gateway-Host per SSH und erneut von getunnelter Remote-CLI; Outputs diffen. Doctor grün, Telefon weiter pending: meist kein nodes approve oder falsches wss-Ziel. Doctor-Auth-Fehler: gemischte Token-Oberflächen lokal/remote.

Empfohlene Ticket-Felder

Anhängen: UTC-Zeitstempel, openclaw --version, Gateway-Health-curl, redigiertes openclaw nodes pending / nodes status, Telefon-Fehlertext (secure endpoint required?), ob Serve vs. nur SSH vs. direct Tailnet.

Symptom → Maßnahmenbaum

A. Telefon: secure endpoint required → wss:// konfigurieren (zuerst Tailscale Serve); kein Klartext-ws auf öffentlicher IP.
B. Pending leer, Telefon dreht → abgelaufener QR, falscher Gateway-Host oder WebSocket-Pairing-Bug (Upgrade 2026.2.28+ vor Deep-Debug).
C. CLI connection refused → Kanada-Loopback, dann Laptop-lsof -i :18789 während SSH-Forward.
D. Freigegeben, sofort Drop → Tailnet-ACL, Akku-Sparmodus, Gateway-OOM; Version vor Restart erfassen.

openclaw doctor
openclaw doctor --lint
openclaw gateway status
openclaw nodes pending
openclaw nodes status
curl -fsS "http://127.0.0.1:18789/health" || true

Anwendungsfall: APAC-On-Call-Telefon triggert Kanada-Automation

Eine On-Call-Ingenieurin in Singapur koppelt ein iPhone-Knoten an das Kanada-Gateway über wss://ca-m4.team.ts.net. Ein Slack-Slash-Command über OpenClaw-Channels fordert per node.*-RPC eine Kamera-Snapshot an; das Gateway orchestriert auf dem M4, das Telefon liefert den Sensorpfad. Latenz dominiert die Pazifik-Strecke, aber das Gateway bleibt online, wenn das MacBook schläft. Freigaben werden mit Ticket-IDs protokolliert; Tokens rotieren quartalsweise ohne Secrets im Chat.

Das Muster funktioniert nur, wenn Pairing, Channels und Tailnet-ACLs dasselbe Plattform-Team besitzen. Laufen Channels auf Kanada, fehlt aber nodes approve am Telefon, sehen Operatoren gesunde Slack-Zustellung und scheitern Knoten-Tools mit Pairing-Fehlern — ein Support-Muster, das Doctor-Snapshots mit nodes status und Channel-Health schnell sichtbar machen.

FAQ

Können iOS oder Android das Gateway hosten?

Nein. Mobile Apps sind nur Knoten. Kanada-M4 als kanonisches Gateway, außer Sie betreiben bewusst isolierte Profile auf einem anderen Host.

Warum ist wss für Remote-Telefon-Pairing Pflicht?

Netzübergreifendes Mobile-Pairing lehnt Klartext-ws:// ab, um Credentials und Device-Fingerprints zu schützen. LAN- und dokumentierte Simulator-Ausnahmen stehen upstream.

Ändert gateway.mode remote den Gateway-Host selbst?

remote ist eine Client-Einstellung. Der Kanada-Mac führt weiter ein lokales Gateway aus. Den M4-Config nicht auf Remote-Loopback zu sich selbst zeigen.

Nur SSH-Tunnel, kein Tailscale am Telefon?

Telefone brauchen erreichbares wss:// (meist Tailscale Serve oder Firmen-Proxy). SSH dient Operator-CLI und Approve, nicht TLS am Handset.

openclaw qr vs. openclaw qr --remote?

--remote kodiert Setup für die Remote-Gateway-URL — auf getunnelter oder tailnet-erreichbarer Operator-Maschine nutzen, damit der QR nicht Laptop-Loopback referenziert.

„Konkurrieren“ mehrere Telefone um das Gateway?

Sie teilen einen Gateway-Prozess und Quotas; keine doppelten Daemons. Geräte labeln und Freigabe-Audit führen.

Pairing ok, Knoten-Tools timeout?

WebSocket-lebendig von langsamem RPC trennen. Gateway-CPU, Disk und Channel-Queues prüfen vor App-Neuinstallation.

Doctor grün über SSH, Telefon scheitert?

Doctor validiert ggf. den Tunnel, das Telefon nutzt anderen wss-Host oder abgelaufenen QR. wss-URL mit Serve abgleichen und nach Scan nodes pending erneut prüfen.