gateway.bind=lan ohne gültige Auth verweigert den Start, OPENCLAW_GATEWAY_TOKEN existiert nur in der interaktiven Shell während LaunchAgent es nicht liest, und nach Config-Änderungen wird angenommen, hybrid-Reload ersetze einen vollständigen Restart bei bind-Wechsel. Der Text liefert eine loopback-vs-lan-Entscheidungsleiter, eine Single-Source-Tabelle für .env und openclaw.json, sechs Schritte inklusive Befehlsblock, die Grenze gateway.reload.mode=hybrid versus manueller Neustart plus gateway.controlUi.allowedOrigins, und Gabeln für refusing to bind without auth, EADDRINUSE und unauthorized; Querverweise auf launchd token, Upgrade und Fernzugriff, Remote Gateway, Diagnoseleiter und install-daemon.
loopback oder lan: OpenClaw Gateway Bind-Entscheidung auf Cloud-Mac 2026
OpenClaw Gateway lauscht standardmäßig auf der Loopback-Adresse – passend, wenn ein Engineer per SSH auf den Cloud-Mac geht und das Dashboard lokal öffnet, oder wenn nur CLI und launchd mit dem Dienst sprechen. Sobald Control UI auf einem zweiten Laptop, mehrere Remote-Clients oder Intranet-Sonden im selben VPC Port 18789 ohne SSH-Tunnel erreichen sollen, muss gateway.bind von loopback auf lan wechseln. OpenClaw 2026 verschärft die Sicherheitslinie: Verlässt der Prozess 127.0.0.1 ohne gültiges gateway.auth.token oder injiziertes OPENCLAW_GATEWAY_TOKEN, startet er nicht – Logs zeigen refusing to bind without auth. Das ist kein Defekt, sondern zwingt Sie, erweiterte Listenfläche und Produktions-Auth im selben Change-Ticket zu dokumentieren.
Entscheiden Sie nicht nur nach Ping-Erreichbarkeit: Einzelpersonen sollten loopback plus ssh -L oder Tailnet bevorzugen (siehe Tunnel-Artikel); lan plus Token lohnt sich, wenn feste RFC1918-Segmente direkt zugreifen oder die Control UI per WebSocket über Subnetze hinweg geöffnet werden muss. Die folgenden fünf Punkte fassen typische Fehlinterpretationen im On-Call zusammen, bevor Modell-Routing oder Channel-Reinstalls diskutiert werden.
Tunnel reicht, lan erzwungen: SSH-Local-Forwarding deckt den Bedarf ab; bind-Wechsel vergrößert nur Angriffsfläche und plist-Drift ohne Nutzen.
lan ohne Token: gateway.bind=lan steht in der Config, aber gateway.auth.mode fehlt oder Token ist leer – Gateway beendet sofort.
Token nur in Shell: manuelles export OPENCLAW_GATEWAY_TOKEN funktioniert interaktiv, LaunchAgent-Job ohne Variable – launchd-Restart-Schleife.
Probe-URL passt nicht zu listen: nach lan weiter curl auf 127.0.0.1 oder healthz ohne Authorization – falscher Offline-Verdacht.
18789 öffentlich ohne App-Auth: Security-Group öffnet 0.0.0.0/0, token und controlUi.allowedOrigins fehlen – Scanner-Rauschen in Logs.
Ohne abgeschlossenes install-daemon zuerst offiziellen Daemon-Pfad und Install-Checkliste durchlaufen, bis loopback unter openclaw gateway status --deep ready ist – sonst vermischen sich Supervisor-Metadaten und bind-Strategie in einem Ticket. Wer EU-Nutzer über Control UI oder Remote-Clients anbindet, sollte dokumentieren, welche Metadaten in Gateway-Logs landen und wie Aufbewahrung im Sinne der DSGVO begrenzt wird; erweiterte lan-Binds erhöhen die Zahl interner Endpunkte, die in Datenschutz-Folgenabschätzungen auftauchen. Halten Sie Token-Rotation, Zugriff auf .env und Log-Minimierung in einem internen Runbook fest, damit Audits nicht nachträglich rekonstruieren müssen, welcher bind-Modus in welcher Woche galt.
.env-Token und openclaw.json: Single Source of Truth im Produktionsbetrieb
In Produktion gehört das Geheimnis nicht gleichzeitig in openclaw.json, plist, Chat und CI-Logs. OpenClaw 2026 empfiehlt, den Gateway-Token in ~/.openclaw/.env (oder einem für launchd sichtbaren Pfad) als OPENCLAW_GATEWAY_TOKEN zu halten; openclaw.json deklariert nur gateway.bind, gateway.auth.mode, gateway.reload.mode und gateway.controlUi.allowedOrigins. Die plist-EnvironmentVariables zeigen auf dasselbe State-Verzeichnis via OPENCLAW_STATE_DIR, damit CI-Benutzer und Login-Home nicht zwei verschiedene .env-Dateien lesen – dieselbe Gabel wie im launchd-token-Artikel, hier für lan ausformuliert.
Vermischen Sie nicht den veralteten Schlüssel gateway.token mit gateway.auth.token: nach Upgrades ignoriert das Schema alte Keys still, Dashboards drehen unauthorized-Schleifen. Migration: Strukturfelder übernehmen, Token auf dem Ziel-Cloud-Mac neu erzeugen und in .env schreiben – keine historischen Klartexte kopieren. Token-Rotation und Zugriff auf .env-Dateien sollten in internen Richtlinien neben Log-Retention stehen; wer personenbezogene Inhalte aus Agent-Sessions verarbeitet, minimiert Volltext in Gateway-Logs und dokumentiert Zweckbindung nach DSGVO-Grundsätzen.
| Feld / Datei | Empfohlen | Verboten | LaunchAgent-Check |
|---|---|---|---|
| ~/.openclaw/.env | OPENCLAW_GATEWAY_TOKEN=<hex>, chmod 600 | Git, Sync-Ordner, Screenshots | WorkingDirectory = CLI |
| openclaw.json | gateway.bind: "lan", gateway.auth.mode: "token" | Klartext gateway.auth.token parallel zu .env | nach bind-Änderung restart |
| gateway.reload.mode | hybrid für weiche Config | bind nur per SIGHUP | Version nach Neustart prüfen |
| controlUi.allowedOrigins | Origin-Whitelist für Remote-Browser | * in Produktion | mit Token gemeinsam testen |
| plist EnvironmentVariables | PATH, OPENCLAW_STATE_DIR; kein Token-Klartext | widersprüchliche Shell-Profile | launchctl print vs deep status |
Geheimnis in .env, Policy in openclaw.json, Supervisor liest dasselbe Verzeichnis – eine Gabel weniger, eine 401-Klasse weniger.
Bei mehreren Remote-Clients WS-URL und Token in Client-Profilen angleichen – siehe Remote-Gateway-Aufteilung. lan-Bind erweitert nur die Listenadresse, ersetzt nicht Bearer-Header und Origin-Policy auf Client-Seite.
Sechs Schritte: Stop, .env, lan-Bind, LaunchAgent, healthz, Client-Auth
Die Schritte setzen launchd-Gateway unter loopback auf einem KVMNODE-Cloud-Mac voraus. Vor dem Change-Fenster openclaw.json, plist-Label und openclaw --version sichern – abgestimmt mit Rollback in Dauerbetrieb. Alles auf dem Gateway-Host ausführen, nicht auf dem Laptop Config ändern und einen entfernten Knoten erwarten.
Alte Prozesse stoppen: openclaw gateway stop, lsof -i :18789 ohne Debug-Leichen – vermeidet EADDRINUSE.
.env schreiben: Zufallstoken in ~/.openclaw/.env, chmod 600; Wert nicht in geteilte Logs echoen.
bind und auth.mode: openclaw config set gateway.bind lan, gateway.auth.mode token, optional gateway.reload.mode hybrid.
LaunchAgent erneuern: openclaw gateway install --force, dann gateway restart; plist gegen which openclaw.
healthz: Authorization: Bearer auf /healthz, nicht nur nackter curl 200.
Client mit Token: Remote-CLI oder Control UI mit gleichem Bearer; bind-Modus und Rotationszeit im Ticket.
export PATH="/opt/homebrew/bin:/usr/local/bin:$PATH"
openclaw gateway stop 2>/dev/null || true
lsof -i :18789
TOKEN=$(openssl rand -hex 32)
echo "OPENCLAW_GATEWAY_TOKEN=${TOKEN}" > ~/.openclaw/.env
chmod 600 ~/.openclaw/.env
openclaw config set gateway.bind lan
openclaw config set gateway.auth.mode token
openclaw config set gateway.reload.mode hybrid
openclaw gateway install --force
openclaw gateway restart
curl -sS -o /dev/null -w "%{http_code}\n" \
-H "Authorization: Bearer ${TOKEN}" \
http://127.0.0.1:18789/healthz
openclaw gateway status --deep
Schritt sechs mindestens zwei Pfade: openclaw channels probe falls konfiguriert, plus Remote-Profil von einem zweiten Rechner – host in WS-URL muss Cloud-Mac-Intranet sein, nicht 127.0.0.1. Remote-401 bei lokalem Grün deutet auf gecachtes loopback-Token oder fehlenden Authorization-Header. Bei split brain nach force zuerst CLI-Ausrichtung, dann erneut bind prüfen.
hybrid-Reload vs gateway restart: welche Felder erzwingen Neustart
gateway.reload.mode=hybrid erlaubt Hot-Reload für Channel-Routing, weiche Agent-Regeln und Sonden-Intervalle ohne lange WS-Unterbrechung – sinnvoll bei Tagesbetrieb mit häufigen Skill-Anpassungen. Bind-Adresse, Port, auth.mode und TLS-Hard-Felder verlangen vollständigen Supervisor-Neustart; SIGHUP nach bind-Änderung erzeugt split views: CLI liest neue Config, Prozess lauscht noch alt. Die Tabelle gehört ins Runbook neben Diagnoseleiter L2 Runtime running · probe failed.
| Änderung | hybrid genügt? | Aktion | Signal |
|---|---|---|---|
| gateway.bind / Port | nein | gateway restart + deep status | lsof = config |
| gateway.auth.mode | nein | restart; ggf. .env rotieren | healthz Bearer 200 |
| channels / Routing | meist ja | config + hybrid oder reload | channels probe grün |
| Modell-Upstream-Keys | meist ja | Hot oder Kurz-Restart | Testnachricht ≠ 401 |
| controlUi.allowedOrigins | versionabhängig; Prod: restart | Array ändern, Browser-Cache leeren | kein CORS-Fehler remote |
Remote Control UI braucht neben Token explizite Origins in gateway.controlUi.allowedOrigins. Öffnen Engineers von https://ops.example.com die UI gegen 18789, muss dieser Origin in der Whitelist stehen – sonst WebSocket- oder CORS-Fehler trotz gültigem Bearer. lan plus allowedOrigins plus Token sind drei unabhängige Variablen; nicht kreuzweise ersetzen.
LaunchAgent-Drift nach jedem bind- oder force-Change prüfen: gateway status --deep, launchctl print für EnvironmentVariables, openclaw doctor für schema und Token-Quelle. Ungeklärter Drift plus hybrid verlängert Koexistenz aus altem Prozess und neuer Datei – Cron-Sonden flackern. Probes aus Cron-Gesundheit müssen dieselbe .env lesen und bei bind=lan Intranet-IP statt localhost nutzen.
Fehlergabeln, M4 vs M4 Pro und Cloud-Mac-Dauerbetrieb
refusing to bind without auth: lan ohne Token – §2-Tabelle, nicht OpenClaw neu installieren.EADDRINUSE: 18789 belegt, lsof owner killen vor force.unauthorized: Bearer-Mismatch oder launchd ohne .env – launchd token.probe failed, Runtime running: Probe-URL, bind und Authorization nicht aligned – Leiter L2.
Standardport: Healthchecks nutzen oft 18789; lan exponiert denselben Port intern – Firewall minimal, nicht weltweit.
healthz: Bearer-Pflicht in Produktion; nackter 200 ohne Auth-Beweis.
hybrid-Grenze: nach bind/auth immer deep status; nur channels-Änderungen hybrid nutzen.
Triage: doctor → deep status → .env und plist → healthz mit Token → Client Origin. Zugeklappter Laptop killt lan-Listen und Remote-Sessions; NAS fehlt launchd-Referenzparität. Dedizierter KVMNODE-Cloud-Mac bündelt bind, Token-Rotation, hybrid und Cron in einem Runbook – auditierbarer als Heimhardware.
| SKU | lan + Multi-Client + CI | Folgerung |
|---|---|---|
| Mac Mini M4 16GB | ein Gateway, wenige Remote-Clients | Produktions-Default; xcodebuild-Konkurrenz beachten |
| M4 Pro 24GB+ | iOS-CI + Skills + lan-Sonden parallel | bei 18789-Jitter in Spitzenwochen |
| Zugeklappter Laptop | lan hilft nicht für 7×24 | nur Experiment |
WeChat ClawBot, Remote-Multi-Client und nightly CI auf einem Host können 16GB unified memory unter Druck setzen – langsame Antworten ohne Auth-Fehler; dann Same-Pool-Isolation oder M4 Pro statt Token-Roulette. Dokumentieren Sie nach Go-Live bind-Modus, plist-Label und healthz-Statuscode neben Region und SKU im Change-Ticket, damit Finance und Compliance erkennen, welcher Knoten Produktions-Auth trägt. Für auditierbare Nicht-Loopback-Binds mit .env-Geheimnissen und LaunchAgent-Abnahme ist KVMNODE Mac-mini-Miete üblich: sechs Regionen, dedizierter Host, Tages- bis Monatsmiete. SKUs: Preisseite, Runbooks: Hilfezentrum, Bestellung: Bestellseite.