OpenClaw 2026 Remote Gateway: SSH-Tunnel, macOS Health Check und LaunchAgent-Checkliste

2026 bietet OpenClaw auf macOS zwei Gateway-Modi: Local (Gateway und App auf einem Rechner) und Remote (Gateway auf einem anderen Mac, Zugriff per SSH-Tunnel oder Direct WebSocket). In Produktion läuft das Gateway typischerweise auf JEXCLOUD Bare-Metal-Mac unter 127.0.0.1:18789; das Notebook mit OpenClaw.app ist nur die „Fernbedienung“. Das ergänzt Knotenwahl und launchd-Token-Fehlersuche: dort „wie installieren und welchen Knoten“, hier „wie verbinden, am Leben halten und prüfen“.

In Reviews werden diese fünf Schmerzpunkte oft unterschätzt:

• Tunnel nicht dauerhaft:SSH-Sitzung endet, die App zeigt noch alten Status, bis der Health Check timeout meldet.
• Token-Doppelspur:Abweichung zwischen launchctl-Umgebung, ~/.openclaw und Token in der App → Pairing- bzw. device-token-Fehler.
• Port / Forward falsch:Standard 18789 belegt oder LocalForward-Ziel falsch – CLI auf Remote ok, localhost am Laptop verweigert.
• UI hinter CLI:CLI-Health grün, macOS-UI weiter pending (openclaw#66306).
• Angriffsfläche:Gateway auf 0.0.0.0 ohne mTLS auf öffentlicher IP ist riskant; empfohlen: 127.0.0.1 + SSH/Tailscale. Für EU-Teams gilt zusätzlich: Token und Logs nicht unkontrolliert duplizieren – relevant für DSGVO-konforme Zugriffskontrolle und Nachvollziehbarkeit.

Merksatz: „Gateway nur auf Loopback, Tunnel für Ausgang, ein Token als Single Source of Truth.“ Wer eine dieser Regeln umgeht, debuggt oft stundenlang.

In den OpenClaw-Einstellungen unter OpenClaw runs wählen Sie meist SSH tunnel oder Direct (ws/wss). Es gibt keine universell richtige Option – nur die passende zu Firewall, Tailscale-Abdeckung und Betriebsgewohnheiten.

Mit SSH-Key aus dem Hilfe-Center und Gateway nur auf Loopback: zuerst SSH-Tunnel. Direct nur, wenn wss://gateway.example.ts.net stabil ist und „Test remote“ dauerhaft grün bleibt.

Remote muss OpenClaw CLI in nicht-interaktiven Shells laufen (pnpm link --global, Symlink nach /opt/homebrew/bin oder /usr/local/bin). Token-Datei: Modus 600, Besitzer = Gateway-User.

Host jex-openclaw-sg
  HostName your-instance.jexcloud.com
  User macuser
  IdentityFile ~/.ssh/jexcloud_ed25519
  LocalForward 18789 127.0.0.1:18789
  ServerAliveInterval 30
  ServerAliveCountMax 3

<key>Label</key>
<string>ai.openclaw.ssh-tunnel</string>
<key>ProgramArguments</key>
<array>
  <string>/usr/bin/ssh</string>
  <string>-N</string>
  <string>jex-openclaw-sg</string>
</array>
<key>RunAtLoad</key><true/>
<key>KeepAlive</key><true/>

Das Gateway selbst via LaunchAgent ai.openclaw.gateway; OPENCLAW_GATEWAY_TOKEN per launchctl setenv oder plist-EnvironmentVariables – nicht parallel in shell profile und plist, sonst Drift.

1. CLI + Gateway remote:openclaw gateway install auf der JEXCLOUD-Instanz; lsof -i :18789 zeigt nur 127.0.0.1.
2. Token schreiben und prüfen:generieren, chmod 600; launchctl setenv OPENCLAW_GATEWAY_TOKEN '…', Gateway-Agent neu starten.
3. SSH am Laptop:LocalForward 18789 in config; ssh -N jex-openclaw-sg; zweites Terminal: curl -s -o /dev/null -w '%{http_code}' -H "Authorization: Bearer $TOKEN" http://127.0.0.1:18789/health → 200.
4. Tunnel-LaunchAgent:launchctl bootstrap gui/$UID ~/Library/LaunchAgents/ai.openclaw.ssh-tunnel.plist – Tunnel nach Login automatisch.
5. macOS-Client:Einstellungen → OpenClaw runs → Remote + SSH tunnel, user@host oder Host-Alias, Test remote bis grün.
6. Patrouille:Health-Skript mit StartInterval (z. B. 300 s) oder CI-SSH-Job; bei Fehler launchctl kickstart -k gui/$UID/ai.openclaw.ssh-tunnel und Exit-Code für On-Call loggen.

Nach erfolgreichem Pairing Onboarding-Sitzung im Client prüfen; bei CLI ok / UI pending die Tabelle in Abschnitt 05 – kein blindes Gateway-Neuinstallieren.

In Produktion HTTP 200 per Skript assertieren, nicht nur UI-Ampeln. Zitierfähige Punkte (Community-Praxis und JEXCLOUD-Beobachtung 2026, keine SLA):

• Standard-Port:18789 – LocalForward muss passen; Mehrinstanzen: extra Ports laut Doku.
• Health-Endpoint:typisch /health mit Bearer Token; Monitoring bei ≠ 200 mit Exit ≠ 0.
• Tunnel-Selbstheilung:KeepAlive + ServerAliveInterval 30 → Wiederherstellung oft 30–90 s.
• APAC-RTT:Ostasien → SG/JP/HK per SSH oft 15–35 ms; Tunnel-Overhead meist < 5 ms.
• Token-Rechte:immer 600; falscher Besitzer → launchd lädt Token ggf. still nicht.

#!/bin/bash
TOKEN="${OPENCLAW_GATEWAY_TOKEN:?}"
CODE=$(curl -sf -o /dev/null -w '%{http_code}' \
  -H "Authorization: Bearer $TOKEN" http://127.0.0.1:18789/health)
[[ "$CODE" == "200" ]] || exit 1

Heim-Internet oder instabiles WLAN als 7×24-Tunnel-Eingang führt durch NAT und Sleep zu „morgens grün, nachmittags rot“. Gateway auf geteiltem VPS kann unter Nachbarlast Health-Aussetzer zeigen; lokaler Mac leidet unter Updates und Keychain-Popups. Teams mit stabiler Fernsteuerung, auditierbaren Tokens und selbstheilendem Tunnel setzen das Gateway oft auf JEXCLOUD Bare-Metal-Mac multi-region: exklusives Apple Silicon, ~120 s Bereitstellung, M4 Pro nach Bedarf. Preise: JEXCLOUD Preisseite; grafische Fehlersuche: VNC.