Fernzugriff

Die meisten Fehler beim Fernzugriff beginnen mit einem schlechten Reflex: Jemand will OpenClaw vom Laptop aus erreichen, also wird schnell ein Port geöffnet und auf das Beste gehofft. Das ist digital gesehen ungefähr so klug wie ein Haustürschlüssel unter der Fußmatte.

OpenClaw bietet ein saubereres Muster. Halte ein Gateway auf einer vertrauenswürdigen Maschine am Laufen, halte es standardmäßig privat und bringe dich selbst per Tunnel oder Tailnet dorthin. Gleiche Bequemlichkeit, deutlich weniger Reue.

Was Fernzugriff in OpenClaw bedeutet

Ein Gateway besitzt den wichtigen Zustand: Sessions, Auth-Profile, Kanäle, Tools und Node-Verbindungen. Deine anderen Geräte sind Clients. Sie verbinden sich mit diesem Gateway, statt jeweils ihre eigene kleine Insel zu betreiben.

Das ist wichtig, weil moderner Fernzugriff in OpenClaw einfacher ist, als viele ältere Anleitungen vermuten lassen. Der Gateway-WebSocket ist der Mittelpunkt. CLI-Befehle, Control UI und WebChat können über denselben Remote-Pfad laufen.

• Gateway-Host: die Maschine, auf der OpenClaw dauerhaft läuft
• Operator-Gerät: dein Laptop, Desktop oder Arbeitsplatzrechner
• Nodes: Smartphones, Tablets oder andere Maschinen, die sich am Gateway anmelden

Der sichere Standard: Gateway auf Loopback lassen

Die beste Ausgangslage ist angenehm langweilig. Binde das Gateway an 127.0.0.1 und hole Remote-Traffic über einen vertrauenswürdigen Transport herein.

Es gibt einen Grund, warum die Branche von Telnet zu SSH gewechselt ist. Die alte Lehre war simpel: Fernzugriff ist nützlich, aber rohe Freigabe altert schlecht. OpenClaw folgt genau diesem Muster. Erst privat, dann bequem.

Wenn das Gateway nur auf Loopback hört, vermeidest du den häufigsten Fehler: einen Management-Port, der länger offen im Internet steht als geplant.

Option 1: Remote über SSH

Wenn du den universellen Fallback willst, nimm einen SSH-Tunnel. Ein weitergeleiteter Port reicht für die meisten Remote-Workflows mit OpenClaw.

ssh -N -L 18789:127.0.0.1:18789 user@host

Dieser Befehl leitet deinen lokalen Port 18789 auf das entfernte Gateway mit demselben Port weiter. Sobald der Tunnel steht, können deine lokalen Tools mit ws://127.0.0.1:18789 sprechen, als würde das Gateway direkt neben dir laufen.

Das ist ideal für:

• CLI-Nutzung vom Laptop aus
• Temporäre Admin-Sessions
• Sicheren Zugriff über fremde Netzwerke
• Maschinen, auf denen du SSH ohnehin mehr vertraust als einer zusätzlichen Netzwerkschicht

Remote-Defaults dauerhaft speichern

Wenn du dich oft verbindest, speichere das Remote-Ziel in deiner Konfiguration. Dann weiß die CLI nach dem Tunnelaufbau direkt, wohin sie sprechen soll.

{
  gateway: {
    mode: "remote",
    remote: {
      url: "ws://127.0.0.1:18789",
      token: "your-token"
    }
  }
}

Ein wichtiges Detail: Wenn du die Gateway-URL direkt überschreibst, gib die Zugangsdaten ebenfalls explizit mit. Das ist keine Schikane, sondern eine sinnvolle Sicherheitsgrenze.

Option 2: Tailscale für den Alltag

Wenn SSH der universelle Fallback ist, dann ist Tailscale oft das angenehmste Alltags-Setup. Es gibt deinen Geräten ein privates Netzwerk, ohne dass du das Gateway öffentlich freilegen musst.

Praktisch gibt es zwei Muster:

• Tailscale Serve: Gateway bleibt auf Loopback, Tailscale übernimmt HTTPS und Routing im Tailnet
• Tailnet-Binding: Gateway bindet direkt an die Tailnet-IP, wenn du im Tailnet wie in einem privaten LAN arbeiten willst

Tailscale Serve

Das ist die saubere Wahl für ein Gateway, das dauerhaft online bleibt. Das Gateway selbst bleibt privat auf dem Host, während Tailscale wie ein bewachter Empfang davorsteht.

{
  gateway: {
    bind: "loopback",
    tailscale: { mode: "serve" }
  }
}

Mit diesem Modus bekommst du meist die beste Mischung aus Sicherheit und Komfort: Loopback auf dem Host, HTTPS im Tailnet und weniger bewegliche Teile auf den Client-Geräten.

Direktes Tailnet-Binding

Wenn du einfachen Netzwerkzugriff von anderen Tailnet-Geräten willst, binde direkt an das Tailnet-Interface und lasse Auth aktiv.

{
  gateway: {
    bind: "tailnet",
    auth: {
      mode: "token",
      token: "your-token"
    }
  }
}

Das ist geradlinig, aber weniger privat als Loopback plus Serve. Für Homelabs gut. Für lockeren Internetzugriff nicht meine erste Wahl.

Option 3: Öffentlicher Zugriff nur wenn es wirklich sein muss

Manchmal brauchst du tatsächlich einen öffentlichen Einstiegspunkt. Vielleicht testest du auf einem Gerät ohne Tailnet. Vielleicht teilst du einen stark kontrollierten Operator-Zugang. In Ordnung. Dann behandle es aber wie Produktionsinfrastruktur und nicht wie eine Abkürzung.

Die OpenClaw-Dokumentation empfiehlt für öffentliche Tailscale-Funnel-Zugriffe einen passwortgeschützten Aufbau. Übersetzt heißt das: Sobald du öffentlich gehst, ist Shared-Secret-Auth keine nette Idee mehr, sondern Pflicht.

{
  gateway: {
    bind: "loopback",
    tailscale: { mode: "funnel" },
    auth: {
      mode: "password",
      password: "replace-me"
    }
  }
}

Wenn du dich gerade fragst, ob du das brauchst, lautet die ehrliche Antwort meistens: eher nicht. SSH oder ein Tailnet ist in der Regel die bessere Lösung.

WebChat und Control UI über Fernzugriff

Hier stolpern viele über alte Denkmuster. WebChat braucht keinen separaten Web-Port mehr. Das aktuelle Muster ist einfacher: Stelle den Gateway-Pfad sauber remote bereit, dann läuft WebChat über denselben Zugang mit.

Ein gutes Remote-Setup deckt damit oft direkt ab:

• Control UI
• CLI-Befehle
• WebChat-Sessions
• Health Checks und Statusabfragen

Wenn du browserbasierten Zugriff von überall willst, kombiniere diesen Guide mit dem Artikel zur WebChat-Einrichtung. Erst das Netzwerk, dann die Chat-Oberfläche.

Remote-Nodes und Browser-Steuerung

Fernzugriff ist nicht nur für dich da. Er hält auch den Rest deines OpenClaw-Systems zusammen.

Stell dir ein dauerhaft laufendes Gateway auf einem Home-Server vor, dein Handy als Node und einen separaten Desktop für Browser-Automatisierung. Das Gateway bleibt der Entscheider. Es empfängt die Nachricht, führt den Agenten aus, ruft bei Bedarf den Browser-Node oder Mobile-Node auf und sendet das Ergebnis zurück.

Wenn du einen Browser auf einem anderen Rechner steuern willst, starte dort einen Node-Host und halte beide Seiten im selben Tailnet oder in einem sicheren Remote-Pfad. So vermeidest du die hässliche Variante dieses Setups: eine zweite öffentliche Kontrollfläche, die du ab dann für immer absichern musst.

Typische Fernzugriffs-Setups

Always-on Home-Server

Lass das Gateway auf einem Raspberry Pi, Mini-PC oder alten Desktop laufen. Greife per Tailscale Serve oder SSH vom Laptop zu. Für viele ernsthafte private Setups ist das der Sweet Spot.

Laptop als temporäres Gateway

Halte OpenClaw lokal auf dem Laptop und tunnele bei Bedarf von einer anderen Maschine hinein. Gut für Reisen. Weniger gut, wenn der Laptop ständig schläft.

VPS als dauerhaftes Gateway

Nutze einen VPS, wenn du stabile Uptime willst und nicht von deinem Heimanschluss abhängen möchtest. Auch dann gilt: öffentlicher VPS heißt nicht automatisch öffentliches Gateway.

Troubleshooting

Der Tunnel steht, aber Befehle schlagen trotzdem fehl

• Prüfe, ob das Gateway wirklich auf Port 18789 lauscht
• Stelle sicher, dass deine Remote-Konfiguration nach dem Forwarding auf ws://127.0.0.1:18789 zeigt
• Bestätige, dass Token oder Passwort zum gewählten Auth-Modus passen

Tailscale verbindet, aber die Control UI lädt nicht

• Prüfe, ob du serve oder direktes tailnet-Binding gewählt hast
• Kontrolliere, dass Tailscale auf beiden Geräten eingeloggt ist
• Stelle sicher, dass die Gateway-Auth-Einstellungen zum Exposure-Modus passen

WebChat läuft lokal, aber remote nicht

• Bestätige, dass du wirklich den Gateway-Pfad freigegeben hast und nicht einem alten getrennten Chat-Port-Modell folgst
• Prüfe Browser-Konsole und Gateway-Logs auf fehlgeschlagene WebSocket-Handshakes
• Teste zuerst mit einem simplen SSH-Tunnel, bevor du die App-Schicht verdächtigst

Remote-Browser-Automatisierung ist wackelig

• Halte den Browser-Rechner im selben Tailnet wie das Gateway
• Stelle sicher, dass der Node-Host gepairt und gesund ist
• Nutze öffentlichen Funnel nicht als ersten Versuch für Browser-Steuerung

Sicherheits-Checkliste für Fernzugriff

• Loopback als Standard: SSH oder Tailscale übernehmen den Zugriff
• Auth bei Non-Loopback-Binds: Token, Passwort oder sauberer Trusted-Proxy-Aufbau
• Gateway nicht beiläufig exponieren: öffentliche Ports haben die unangenehme Angewohnheit, offen zu bleiben
• Ein Gateway behält die Kontrolle: Nodes sind Peripherie, keine konkurrierenden Gateways
• Erst den einfachen Pfad testen: wenn SSH-Tunnel stabil läuft, wird der Rest des Stacks deutlich leichter zu debuggen

Gerade der letzte Punkt ist wichtiger, als er klingt. Guter Fernzugriff lebt weniger von cleverem Networking als von klaren Grenzen. Ein Host besitzt den Zustand. Alles andere erreicht ihn bewusst und kontrolliert.

Was du als Nächstes tun kannst

• Lies Home Server & Raspberry Pi, wenn dir noch ein stabiler Host fehlt
• Richte WebChat ein, sobald dein Remote-Pfad funktioniert
• Prüfe die Security Best Practices, bevor du irgendetwas breiter als deinen Laptop zugänglich machst