OpenClaw Gateway 24/7 auf einem Cloud-Mac scheitert häufiger an „kommt nach Reboot nicht zurück“, „Logs fressen die Platte“ und „Prozess läuft, Kanäle/Modelle schweigen“ als an der Erstinstallation. Der Leitfaden richtet sich an Teams jenseits des Tutorials, die OpenClaw als Produktionsinfra behandeln: sechs Unattended-Mythen, eine Triage-Tabelle Hostprozess / Container / Reverse-Proxy, kopierbare launchd- und systemd-Snippets, Log- & Festplatten-Snapshots sowie ein Sechs-Schritte-Self-Heal-Runbook plus drei Bereitschafts-Kennzahlen. Nach der Lektüre lässt sich entscheiden, ob plist/Unit, Volumes oder die Modell-/Kanal-Schichten in fester Reihenfolge angegangen werden.
127.0.0.1 über TLS-terminierte Kanten curlen, liefern „Metriken grün, Nutzer rot“—mit dem TLS-Reverse-Proxy-Leitfaden quergelesen.Als Nächstes trennen wir „Prozess sichtbar“ von „Nachrichten Round-trip“, dann landen wir bei macOS- und Linux-Supervisorn.
Schicht 1 (Hostprozess) klärt, ob das Gateway-Binary bzw. der Node-Prozess unter dem richtigen Benutzer überdauert, die vorgesehene Schnittstelle bindet und aktuelle Tokens sowie Datenverzeichnisse sieht.
Schicht 2 (Container) engt auf Compose-Netze, publizierte Ports und Volumes ein—wenn Host-curl und In-Container-curl divergieren, mit der Docker-Netzwerk-Triage-Checkliste starten.
Schicht 3 (Proxy) umfasst TLS, WebSocket-Upgrade, Pfad-Stripping und Timeouts—502/Handshake an der Kante folgen der Nginx/Caddy-Checkliste.
Auf Remote-Macs sitzt Schicht 3 oft hinter SSH-Tunneln oder privatem DNS; „localhost-curl ok“ ist nicht „öffentliche Callbacks ok“. Für Slack/Telegram-ähnliche Kanäle OAuth-Scopes mit der Kanal-Troubleshooting-Checkliste verifizieren.
Wenn Gateway CI-Builds und Cron den Host teilt, Disk-I/O und CPU-Konkurrenz beobachten: Build-Spitzen bremsen Log-fsync und TLS-Handshakes und zeigen intermittierende Timeouts—nicht harten Totalausfall. Build-Cache getrennt von Gateway-Datenpfaden überwachen und Schreibrate beider Pfade alerten, damit Infra-Jitter nicht fälschlich als Modellqualitäts-Regression etikettiert wird.
| Symptom | Verdachtsschicht zuerst | Nächste Aktion (ausführbar) |
|---|---|---|
| Supervisor „läuft“, kein Listener | Prozess / plist·Unit | Einmal im Vordergrund als derselbe Benutzer; WorkingDirectory und ProgramArguments prüfen |
Host ok, In-Container-curl zum Upstream scheitert | Container-Netz | Compose-Netz, publizierte Ports, irrtümliches Host-Networking inspizieren |
| Domain-502 bei ok Loopback | Reverse Proxy | proxy_pass, Upgrade-Header, read_timeout angleichen |
| UI ok, Kanäle still | Kanal / Callback-URL | Webhook-URLs und TLS-Ketten gegen Releases auf Drift prüfen |
| Zufällige Hänger, einstellig freie GB | Festplatte / Logs | du per Tabelle unten; Log-Level senken |
| Hohe Last, Modell-429 | Modell-Egress / Warteschlange | Drosseln, umleiten, Backoff verlängern; Liveness nicht gesunde Pods killen |
launchd sollte UserName, WorkingDirectory, Stdout/Stderr-Pfade und ein ThrottleInterval zusammen mit KeepAlive festhalten, damit Crash-Stürme den Host nicht pegeln.
systemd koppelt Restart=on-failure mit RestartSec und dokumentiert EnvironmentFile plus LimitNOFILE. Beide müssen den Dienst nach Ende der SSH-Session am Leben halten—das ist der Kernunterschied zwischen Unattended-Betrieb und interaktivem Debug.
Wenn Docker das Gateway kapselt, überwacht launchd/systemd meist docker compose up -d (oder einen Wrapper), nicht Node direkt—Health-Checks auf Compose oder die HTTP-Probes aus dem Kubernetes-Health-Check-Leitfaden verlagern, damit der Host keinen eingefrorenen Container für gesund hält.
<!-- Beispiel-Keys—Pfade/Benutzer/Befehl an Installation anpassen --> <key>KeepAlive</key><true/> <key>ThrottleInterval</key><integer>30</integer> <key>StandardOutPath</key><string>/var/log/openclaw/gateway.out.log</string> <key>StandardErrorPath</key><string>/var/log/openclaw/gateway.err.log</string>
# /etc/systemd/system/openclaw-gateway.service (Auszug) [Service] Restart=on-failure RestartSec=20 EnvironmentFile=-/etc/openclaw/gateway.env LimitNOFILE=1048576
Log-, Konfigurations- und Datenpfade getrennt mounten, damit Backups und Quotas unabhängig bleiben. Rotation muss Host-Plaintext-Logs und Docker-json-file-Treiber abdecken—sonst hinterlassen gelöschte Container weiter riesige Layer auf der Platte. Mindestens Bearer-Tokens, Webhook-Secrets, E-Mail-Adressen und Kanal-ID-Suffixe redigieren; vor SIEM-Weiterleitung Allow-Liste-Felder statt fragiler Blacklist-Regexe bevorzugen.
Zentrale Logs oder ein SIEM können personenbezogene Daten enthalten (z. B. E-Mails, Nutzer-IDs in Kanal-Metadaten) und unterliegen damit Anforderungen nach DSGVO bzw. Datenschutzrecht—Rechtsgrundlage, Zweckbindung, Aufbewahrungsfristen und ggf. Auftragsverarbeitung vor Produktivgang dokumentieren.
Mit dem Post-Install-Doctor-Leitfaden abstimmen: Doctor-Zusammenfassungen in Tickets einfügen, keine vollen Umgebungsdumps in Chats.
Auf zentralen Logging-Plattformen für OpenClaw eine eigene Retention- und Sampling-Policy definieren—bei Incidents Sampling erhöhen, nach dem Change-Fenster automatisch zurücksetzen, damit „temporäres Debug“ nicht zum Dauerstandard wird.
| Pfadtyp | Typischer Ort (Beispiele) | Check / Aktion |
|---|---|---|
| Gateway-Textlogs | /var/log/openclaw/ oder Projekt-logs/ | du -sh + Schwellen-Alerts; newsyslog/logrotate |
| Docker-Graph | Vom Graph-Treiber verwaltet | docker system df; json-file-Größe deckeln |
| Arbeitsverzeichnisse & Cache | ~/.openclaw, Build-Caches | Vor Upgrades sichern; veraltete Session-Dateien prunen |
| Freier Platz Root-Volume | / | df -h; unter ~15 % frei Menschen pagern |
# Schneller Größen-Snapshot (Pfade an Installation anpassen) du -sh /var/log/openclaw 2>/dev/null docker system df 2>/dev/null df -h /
Vorsicht: vor Datenlöschung Volumes und Secrets als ungenutzt bestätigen; in Produktion eher expandieren + rotieren statt blindem rm -rf.
du mit Stand vor 24h vergleichen, um Log-Bursts zu sehen.compose restart des Dienstes, bei Bedarf Host-Reboot; Exit-Codes erfassen.Dieser Artikel deckt Langläufer-Supervision, Log-/Platten-Hygiene und Hänger-Triage-Reihenfolge auf Remote-Macs ab; der Doctor-Leitfaden Post-Install-Validierung; die Docker-Netzwerk-Checkliste Container-Routing; der Reverse-Proxy-Leitfaden TLS/WebSocket; der Health-Probe-Leitfaden Orchestrator-Semantik. Dokumentation in der Reihenfolge Installation → Netz → Kanten → Steady State halten, um doppelte Runbooks zu vermeiden.
Sleep-Zyklen, Patch-Takt und wechselnde Netze lassen sich schwer schriftlich in SLAs gießen; geteilter Speicher und Bandbreite mit Tagesarbeit erschweren Isolation von Hängern und Log-Stürmen. Ein vertraglich dedizierter Remote-Mac entkoppelt Energiepolitik, Plattenklassen und Egress von individuellen Gewohnheiten.
Wenn gleiche Region wie CI-Tester, geringe Sleep-Wahrscheinlichkeit und planbare Platte/Bandbreite für OpenClaw plus Automatisierung nötig sind, bieten MACCOME-Cloud-Macs eine ruhigere Ausführungsebene: mit Mac-mini-Mietpreisen starten, dann regional bestellen—Singapur, Tokio, Seoul, Hongkong, Virginia oder Silicon Valley. Verbindungsabläufe im Hilfe-Center.
FAQ
Nach Reboot—zuerst Daemon oder Konfiguration?
Im Vordergrund ausführen, um lesbare Konfiguration zu belegen, danach plist/Unit-Umgebung und Pfade prüfen. Mehr Installationsschritte im Doctor-Troubleshooting-Leitfaden.
Können Logs die Platte füllen?
Ja—typisch unbeaufsichtigt. Rotation, Alerts und Pipeline-Redaktion ergänzen. Stufen vergleichen unter Mac-mini-Mietpreisen.
UI lädt, aber keine Antworten?
Zuerst Modell, Kanal, dann Warteschlange triagieren—nicht nur neu starten. Querlesen: Kanal-Troubleshooting-Checkliste.
Remote-Mac schläft weiter?
Energieeinstellungen anpassen und auf Supervisoren für Relaunch setzen; Wartungsfenster beim Anbieter klären. Im Hilfe-Center nach Konnektivitäts-Stichworten suchen.