2026 OpenClaw mit WhatsApp auf Linux-Cloud-VPS: QR-Kopplung, Session-Persistenz, Mehrkanal — reproduzierbare Schritte und FAQ zu Abbrüchen vs. HTTP 429

WhatsApp ist der Kanal, den Kundinnen und Kunden ohnehin nutzen — am Gateway ist er aber auch der lauteste Adapter: QR-Fenster laufen schnell ab, Session-Dateien sind kritisches Gut, und Meta-seitige Drosselung wirkt oft wie „verbindet nicht“, wenn man Transportabbrüche nicht von HTTP-429-Stürmen trennt. Dieser Beitrag skizziert einen nachvollziehbaren Pfad für OpenClaw auf einem Linux-Cloud-VPS (2026): einmal scannen, Zustand unter dediziertem OS-Benutzer dauerhaft speichern, Telegram oder Slack parallel betreiben ohne gemeinsame Secrets — und Störungen schichtweise triagieren statt blind neu zu starten.

Reproduzierbares Setup: VPS vorbereiten, QR koppeln, erste Nachricht

Legen Sie einen Nicht-Root-Benutzer an (z. B. openclaw) und ein beschreibbares State-Root, z. B. /var/lib/openclaw/whatsapp, mit korrekter Eigentümerschaft. Installieren Sie OpenClaw wie auf dem restlichen Host üblich — Tarball oder Container —, aber binden Sie das Session-Verzeichnis als Host-Volume, damit Rebuilds die Kopplung nie verwerfen. Starten Sie das Gateway einmal im Vordergrund, lesen Sie QR-String oder ASCII-QR aus den Logs, scannen Sie mit dem Firmenhandy innerhalb des dokumentierten Timeouts, und bestätigen Sie „connected“, bevor Sie den Prozess in den Hintergrund legen.

Öffentliche Ports und Management-Ebene sollten Sie konsistent mit Ihrer VPS-Härtung absichern; eine kompakte Matrix dazu finden Sie hier: OpenClaw Linux-VPS: minimale Angriffsfläche, Firewall, Loopback und SSH- vs. HTTPS-Matrix. Unterschiede zwischen Linux-VPS und Cloud-Mac (launchd vs. systemd) behandeln wir in einem eigenen Artikel der Serie; hier zählt zuerst, dass der Session-Pfad über Reboots und Container-Rebuilds hinweg identisch bleibt.

# ~/.config/systemd/user/openclaw-whatsapp.service
[Service]
WorkingDirectory=/var/lib/openclaw/whatsapp
ExecStart=/usr/local/bin/openclaw gateway --profile whatsapp
Restart=on-failure
RestartSec=5

Aktivieren Sie lingering für den Dienstbenutzer, falls die Unit nach Logout weiterlaufen soll, und rotieren Sie nur Gateway-Logs — niemals aktive Session-Dateien mitten im Schreibvorgang. Nach erfolgreicher Kopplung einmal bewusst neu starten: lädt die Session ohne neuen QR, stimmt der Persistenzpfad.

Session-Persistenz: was Reboots und Image-Upgrades überleben muss

Behandeln Sie den WhatsApp-Session-Store wie eine Passwortdatenbank: auf der Platte verschlüsselt falls unterstützt, Rechte 0700, verschlüsselte Offsite-Backups, und keine Kopien auf Entwickler-Laptops „zur Bequemlichkeit“. Die Kopplung bindet Kryptomaterial an die Gateway-Identität; das Verzeichnis unkontrolliert auf einen zweiten VPS zu klonen erzwingt meist frischen QR und kurz doppelte Outbound-Registrierung — genau das Muster, das Anti-Abuse-Drosseln auslöst.

Snapshots nur bei gestopptem Prozess; heiße Kopien riskieren korrupte Paare, die wie zufällige Logouts wirken. Bei Blue/Green deployen Sie dasselbe Volume in die neue Instanz, bevor Sie Traffic umschalten, und pensionieren die alte VM erst, wenn Senden und Empfangen auf dem neuen Knoten funktionieren.

Pflegen Sie Session-Pfad und Unit-Name im Runbook, halten Sie State von flüchtigen Partitionen fern (keine Symlinks nach /tmp), und pinnen Sie die Gateway-Paketversion neben der Unit, damit Rollbacks zu Layout-Änderungen in den Release Notes passen.

Mehrkanal: Telegram, Slack oder Discord parallel

Führen Sie getrennte Profile oder Prozesse pro Kanal, jeweils mit eigenem Token- bzw. Session-Root, und eine gemeinsame Outbound-Warteschlange, damit Tool-Antworten nicht über Netze hinweg vermischt werden. WhatsApp darf keine Telegram-Umgebungsvariablen lesen und umgekehrt; ein falscher Eintrag in .env genügt, um Traffic in den falschen Adapter zu routen, während Healthchecks noch grün sind.

Zu Pairing, Allowlists und Deduplizierung, wenn zwei Chat-Netze ein Modell speisen, gelten dieselben Prinzipien wie bei anderen Dual-Kanal-Setups in dieser Serie — der Transport weicht ab, die Autorisierungslogik nicht.

Gestufte Triage: schlichter Abbruch vs. 429-Drosselung

Schicht 1 — Erreichbarkeit: prüfen Sie Outbound UDP/TCP zu WhatsApp-Endpunkten vom VPS selbst, nicht vom Laptop über SSH. Sporadischer Verlust bei kleinen Providern korreliert oft mit aggressiven Middleboxes; stabiler Egress oder Resolver kann mehr bringen als reine Versionsupdates von OpenClaw.

Schicht 2 — Session-Integrität: melden Logs Konflikt oder Multi-Device-Logout, darf nur ein primärer Writer das Session-Verzeichnis anfassen. Bridges, die sich mit derselben Nummer anmelden, verdrängen Ihr Gateway oft ohne klaren Fehlertext.

Schicht 3 — Limits: bei wiederholtem HTTP 429 oder generischen Throttle-Hinweisen Send-Rate pro Minute instrumentieren, doppelte Auto-Antworten zusammenführen und jitternden Backoff vor tool-lastigen Retries einplanen. 429 ist ein Budgetproblem, kein Passwortproblem — API-Keys rotieren hilft nicht, wenn schlicht zu schnell gesendet wird. Wenn einzelne Chats noch zustellen, andere aber nicht, suchen Sie nach Fan-out (ein Inbound erzeugt viele Outbounds) und bündeln Sie Benachrichtigungen. Wenn parallele Apple-CI-Pipelines ebenfalls unter strikten Minutenbudgets leiden, lohnt sich ein separater Pfadplan: Xcode Cloud, Minutenpaket und Cloud-Mac (Archive, Notarisierung, TestFlight).