2026 OpenClaw Kanal-Setup
Slack, Discord & Telegram Berechtigungen, OAuth & Triage bei „verbunden, aber stillem“ Bot

Sechs Kanalsymptome, die „verbunden“ wirken, sich aber tot anfühlen

Kanalprobleme werden oft als „das Modell ist kaputt“ oder „Compose-Netzwerk schon wieder“ abgelegt. Bevor Sie Images oder network_mode ändern, klassifizieren Sie das Verhalten mit der Liste unten und vergleichen Sie mit der Docker-Netzwerk-Triage-Tabelle, damit zwei parallele Änderungen die Ursache nicht verwischen.

1. Fehlende Eingangsereignisse: Die Admin-Oberfläche zeigt online, doch neue Kanalnachrichten erzeugen keine Gateway-Logzeilen—häufig Slack-Event-Abonnements aus, Discord-Gateway-Intents fehlen oder der Telegram-Privacymodus blockiert Gruppen.
2. Nur DMs, keine Kanäle: OAuth-Scopes oder Bot-Beitrittsrichtlinien decken nur DMs ab; Kanalnachrichten werden still verworfen—Kanallisten und Bot-Mitgliedschaft prüfen.
3. Befehle werden geparst, aber nie geantwortet: Eingangslogs existieren; Antworten blockieren groupPolicy, Thread-Regeln oder Nur-Erwähnen-Richtlinien—oft Routing auf einen leeren Agenten oder Berechtigung verweigert.
4. Intermittierende OAuth-/Token-Abläufe: Alles grün in der Konsole, Stunden später rot—meist Refresh-Tokens, die nicht zurück in den Secret Store geschrieben werden, oder Container-Neustarts ohne denselben .env-Mount.
5. Workspace- oder Guild-Verdrahtungsfehler: Ein Prozess bindet mehrere Slack-Workspaces oder Discord-Server; zusammengeführte Konfigurationen routen Callbacks auf die falsche URL.
6. Falsche Schuldzuweisung an die Modellebene: Kanäle sind gesund, aber Upstream-429/5xx lässt Nutzer glauben, der Bot sei tot—Gateway- versus Provider-Logverhältnisse prüfen und zum Provider-Failover-Artikel zurückkehren.

Diese sechs Klassen zusammen mit kürzlichen allowedOrigins-Änderungen und Image-Rollouts auf dasselbe Change-Ticket schreiben, damit der On-Call innerhalb von fünf Minuten einen Zweig wählen kann.

Tabelle 1: Drei-Schichten-Triage—Gateway, Kanäle oder Modell zuerst?

Diese Matrix entscheidet, welche Schicht Sie zuerst inspizieren; sie ist nicht exklusiv. Jede Zeile sollte auf einen konkreten nächsten Befehl oder Log-Schlüsselwort abbilden. Skizzieren Sie drei Spalten auf Papier: nutzersichtbares Symptom, erste Auffälligkeit in Gateway-Logs und Upstream-Modell-HTTP-Codes. Bleibt die mittlere Spalte leer, pausieren Sie vor Provider-Änderungen; zeigen die rechte Spalte zuerst 429s, hilft OAuth zehnmal neu zu autorisieren nicht gegen Abrechnungsprobleme.

Zusammen mit dem Docker-Netzwerk-Artikel behandeln Sie fehlgeschlagene Kanal-Probes im Container als Schicht 0: bestätigen Sie, dass die CLI im selben Compose-Netz Gateway erreicht, bevor Sie diese Tabelle nutzen; sonst wirkt Slacks Webhook-Konsole gesund, während der Host nur Timeouts sieht.

Drei Kanal-KPIs für das Dashboard

Diese Metriken verwandeln „der Bot fühlt sich fest“ in alarmierbare Zahlen; Feldnamen an Gateway-Logging angleichen. Stundenbuckets gegenüber Sekundenrauschen bevorzugen, damit Nacht-Pages sinnvoll bleiben.

1. Inbound Event Rate (IER): Kanalbestätigte Ereignisse geteilt durch sends der Fachseite pro Fenster; dauerhaft unter 0,9 deutet auf OAuth und Abonnements, nicht auf GPUs.
2. Routing Hit Rate (RHR): Anteil des Eingangsverkehrs, der dem beabsichtigten Agenten zugeordnet ist; wenn IER passt, RHR aber sinkt, sind Richtlinien oder Kanalkarten verrottet.
3. Reply Completion Rate (RCR): End-to-End-Erfolg von Eingang bis HTTP 200 vom Modell; wenn IER und RHR hoch, RCR niedrig, priorisieren Sie die Modellebene.

Community-Dokumentation betont 2026 weiter openclaw channels status --probe; Probeergebnisse neben diesen drei Raten plotten, um nicht reproduzierbare „Reconnect und hoffen“-Fixes zu vermeiden. Wenn Sie HTTP-Probes aus dem Gateway-Health-Artikel konfiguriert haben, müssen Probe-URLs demselben Reverse-Proxy-Pfad wie echte Kanal-Callbacks folgen—Loopback-only-Probes bei öffentlichen Callbacks auf einer anderen Zertifikatskette erzeugen „alle Monitore grün, alle Nutzer rot“.

Eine manuelle Abgleichgewohnheit ergänzen: wöchentlich zehn Nutzernachrichten stichprobenartig prüfen, ob Plattform-Nachrichten-ID, Gateway-Request-ID und Modell-Trace-ID über Logs hinweg vorkommen; fehlende Verknüpfungen bedeuten kaputtes Structured Logging—Felder vor dem Skalieren reparieren.

Sechs-Schritte-Runbook: von Probes zu reversiblen OAuth-Änderungen

1. Blast Radius einfrieren: Image-Tags, Env-Hashes und die letzten drei Compose-Änderungen erfassen—Kanalregressionen liefern sich oft mit Rolling Releases. Wenn allowedOrigins oder TLS-Zertifikate am selben Tag wechselten, dokumentieren Sie, wie Sie auf den vorherigen Zertifikatsfingerabdruck zurückrollen, damit OAuth-Callbacks und CORS nicht gemeinsam scheitern.
2. Gateway-Baseline etablieren: gateway status auf dem Host oder im Container mit dem Doctor-Artikel abgleichen. Bei systemd oder launchd Restart-Richtlinien prüfen—schnelle Restarts triggern Plattform-Rate-Limits auf Kanal-WebSockets.
3. Pro Plattform autorisieren: Slack OAuth und Scopes erneut durchlaufen; Discord Intents aktivieren und Bot neu einladen; Telegram BotFather-Privacy anpassen oder @mentions in Gruppen sicherstellen. Nach der Autorisierung auf Plattform-Cache-TTL warten (oft 5–15 Minuten); nicht zehn Re-Auth-Versuche hintereinander feuern.
4. Minimalen Dialog beweisen: Ein Kanal, ein Agent, keine Zusatzrichtlinien für einen Ping-Pong-Test, danach groupPolicy wieder aktivieren. Testnachrichten mit Präfix versehen, damit Logs grep-freundlich statt öffentlich laut sind.
5. Modellebene kontrastieren: Wenn Ping-Pong weiter scheitert, 30 Sekunden Logs auf 429-Anteil bemustern, bevor Sie Provider wechseln. Wenn 429s auf einem Key clustern, prüfen Sie, ob Consumer-Tier-Keys mit Pay-as-you-go-Keys vermischt wurden.
6. Das Runbook zurückschreiben: Token-Rotation und Secret-Pfade im selben Repo wie Docker-Netzwerk-Notizen ablegen, damit nicht nur ein Laptop releasen kann. Mitarbeitern minimal notwendige Read-only-Scopes geben; Master-Keys in KMS oder sealed secrets halten. Enthalten Logs oder Exporte personenbezogene Daten aus Kanälen, klären Sie Zweckbindung, Aufbewahrung und ggf. Auftragsverarbeitung nach DSGVO mit Dienstleistern und dokumentieren Sie Zugriffe.

Slack, Discord und Telegram—Schnellchecks auf einer Seite

Führen Sie diese gegen jede Anbieterkonsole aus; vertrauen Sie nicht auf veraltete Screenshots. Wenn Sie Staging- und Produktions-Workspaces pflegen, fügen Sie eine eigene Spalte für Callback-Hostnamen hinzu, damit Staging-Zertifikate nie an Produktions-DNS gebunden werden.

• Slack: App- und Bot-Token gültig; Event-Abonnement-URLs zeigen auf das öffentliche Gateway, das Sie tatsächlich betreiben; Socket Mode wird nicht unbeabsichtigt mit HTTP gemischt. Bei Enterprise Grid prüfen, ob jede Workspace-Installation denselben OAuth-Client referenziert, sonst erhalten Regionen nie Events.
• Discord: Message Content Intent und Server Members Intent entsprechen dem echten Bedarf; der Bot ist in Zielkanälen sichtbar; Kanal-Overrides verweigern keine Sends. Discords Berechtigungsdiagnostik nutzen statt nur Rollennamen zu lesen.
• Telegram: Webhook versus Long Polling—eine Variante wählen; Zertifikate und Callback-URLs dürfen nach Rolling Releases nicht auseinanderlaufen; Gruppen können unter Privacymodus explizite Mentions verlangen. Selbstsignierte Zertifikate müssen dennoch Ports und TLS-Versionen bereitstellen, die Telegram erwartet; Zertifikate im eigenen Änderungsfenster rotieren.

Alle drei Plattformen hängen an stabilen Egress-IPs. Heim-DSL oder VPNs mit wechselnden Exit-Knoten wirken wie missbräuchlicher Webhook-Traffic. Das passt zur Multi-Region-Cloud-Mac-Empfehlung zu festen Regionen und auditierbarem Egress—verschieben Sie die Steuerungsebene auf einen nachweislich erreichbaren Host, bevor das Team vom Bot abhängt. Inhalt in Gruppenchats kann personenbezogen sein; technische Privacymodus-Einstellungen mit organisatorischen Vorgaben zu Datenminimierung und Zugriffskontrolle (einschließlich DSGVO, wo anwendbar) abstimmen.

Warum ein persönlicher Laptop teamweite OpenClaw-Kanäle nicht trägt

Standby, VPNs und lokale Proxies ändern Egress-IPs und TLS-Fingerabdrücke, daher scheitern OAuth-Callbacks und Vendor-Allowlists zufällig. Geteilte Laptops können Token-Rotation und Audit-Felder nicht zentralisieren. Gateway und Kanal-Worker auf einer bereitzuschaltenden, stabilen Egress-Ebene betreiben, um mit Team-Agent-Richtlinien übereinzustimmen. Für EU-Teams sind zentrale Geheimnisverwaltung und nachvollziehbare Logs unter Datenschutzgesichtspunkten (einschließlich DSGVO: Zweckbindung, Zugriffsbeschränkung) leichter abzusichern als verteilte Privatgeräte.

Für Topologien mit dauerhaftem Betrieb, festen Callback-Domains und vorhersagbarem Egress bietet MACCOME Mac mini M4 / M4 Pro Cloud-Hosts in Singapur, Japan, Korea, Hongkong, US-Ost und US-West—geeignet für Gateway plus Apple-Tooling. Nach der Kanal-Triage mit dem SSH-versus-VNC-Leitfaden und dem Hilfe-Center kombinieren, anschließend Mietpreise und Regionsseiten finalisieren.

Pilotmuster: 24 Stunden IER und RCR auf einem dedizierten Test-Host mit einem Kanal messen, bevor ein Produktions-Workspace geöffnet wird—eine große Community sofort aktivieren und rot zu werden vermeiden.