2026 OpenClaw auf Slack für Linux-Cloud-VPS: Bot-Tokens, Event Subscriptions, Callback-URL zum Gateway — reproduzierbares Setup und gestufte 403-/Replay-Troubleshooting-FAQ

Slacks Event Subscriptions verlangen einen stabilen HTTPS-Endpunkt, prüfbare Signaturen und schnelle JSON-Antworten. Wenn OpenClaws Gateway auf einem kleinen Linux-VPS läuft, sind die meisten Vorfälle nicht „Slack liegt aus“, sondern TLS an der Außenkante, Pfad-Diskrepanzen zwischen Slack-App und Reverse-Proxy oder Auth-Schichten, die 403 liefern, bevor das Signing Secret überhaupt geprüft wird. Legen Sie zuerst ein reproduzierbares Layout (Installation, Bind-Adressen, TLS) wie in 2026 OpenClaw Gateway in Produktion auf Linux: openclaw onboard, openclaw doctor und --fix, HTTPS mit Nginx oder Caddy, Upgrade und Rollback fest, und richten Sie Token und Callback-URLs anschließend so aus wie bei anderen Chat-Oberflächen in 2026 OpenClaw mit Telegram und Discord im Doppelkanal: Bot-Konfiguration, Pairing-Freigaben, Berechtigungsmatrix und FAQ zu Mehrkanal-Konflikten — damit bleiben Pairing und Allowlists langweilig und wiederholbar.

Was Slack auf der Leitung erwartet

Legen Sie eine Slack-App an oder nutzen Sie eine bestehende, aktivieren Sie Event Subscriptions und tragen Sie eine Request-URL ein, die auf Ihren VPS-Hostnamen über Port 443 zeigt. Slack sendet zuerst url_verification; Ihr Stack muss die Challenge-JSON innerhalb weniger Sekunden zurückgeben, ohne den Body doppelt zu puffern. Nach erfolgreicher Verifikation liefert Slack Umschläge mit X-Slack-Signature und X-Slack-Request-Timestamp. Das Signing Secret gehört in eine SecretRef oder eine nur für den Gateway-Benutzer lesbare Datei — niemals in Git, niemals in weltlesbare /etc-Drop-ins. Bot-Tokens (xoxb-) treiben Web-API-Aufrufe wie Antworten im Kanal; begrenzen Sie Scopes strikt auf Kanäle und Methoden, die Sie wirklich nutzen, damit ein geleakter Token nicht den ganzen Workspace durchwandern kann.

Callback-URL → TLS-Edge → Loopback-Gateway

Führen Sie das Gateway an 127.0.0.1 auf dem Port, den Ihre OpenClaw-Dokumentation nennt, terminieren Sie TLS bei Nginx oder Caddy und leiten Sie sowohl normale POST-Body als auch WebSocket-Upgrades weiter, falls Ihre Steuerfläche sie braucht. Der öffentliche Pfad in Slack (z. B. /slack/events) muss exakt zum location-Block passen, der TLS beendet — ein Slash-Mismatch oder doppeltes Präfix (/openclaw/slack/slack/events) reicht, damit Slack 403 vom Proxy sieht, während curl gegen Loopback weiter „grün“ wirkt. Loggen Sie den Upstream-Status getrennt vom Gateway-Prozess, damit Sie erkennen, ob der Edge antwortete, bevor der Node-Worker lief.

curl -sS -D- \
  -H 'Content-Type: application/json' \
  -d '{"type":"url_verification","challenge":"ping"}' \
  https://claw.example.com/slack/events

Slash-Commands, Shortcuts und Interactivity-URLs

Event Subscriptions sind nur ein Eingang. Slash-Commands, Nachrichten-Shortcuts und Block-Kit-Interactivity deklarieren jeweils eigene Request-URLs in den Slack-App-Einstellungen — jede muss dieselbe TLS-Kante mit derselben Pfaddisziplin erreichen. Wenn Sie Events an OpenClaw routen, Interactivity aber noch auf einen alten Tunnel-Host zeigen, erleben Betreiber „Buttons reagieren nicht“, während DMs weiterlaufen — eine typische Split-Brain-Konfiguration nach Migration. Halten Sie alle Callbacks auf demselben Zertifikat und derselben Logging-Pipeline, damit 403-Jagden eine Journal-Abfrage wiederverwenden.

Reproduzierbare Checkliste (Linux-VPS)

Provisionieren Sie Ubuntu LTS oder Debian 12, installieren Sie OpenClaw über denselben Paketkanal, den das Team in Produktion pinnt, und führen Sie das Onboarding einmal aus einer UTF-8-Shell mit dediziertem UNIX-Benutzer aus. Öffnen Sie 22/tcp nur von Admin-IPs, 80/443 weltweit für ACME und Slack-Callbacks, und halten Sie den Gateway-Port von 0.0.0.0/0 fern. Sobald openclaw gateway status den Loopback-Listener zeigt, Zertifikate ausstellen, Proxy neu laden und erst danach den Schalter für Event Subscriptions in Slack aktivieren. Sichern Sie ~/.openclaw und den Workspace vor Secret-Rotationen, damit Rollback „Tarball zurück, Unit neu laden“ bleibt — keine Archäologie.

Gestufte 403, Replay und doppelte Zustellung — FAQ

Beim Debuggen gehen Sie die Schichten der Reihe nach durch — jede Stufe hinterlässt andere Fingerabdrücke in Access- und Anwendungslogs.

Slack kann Event-Zustellungen wiederholen; gestalten Sie Handler idempotent über event_id (oder deterministisch abgeleitete Dedupe-Keys). Wenn Sie Erfolg echoen, bevor Nebenwirkungen fertig sind, kann ein Retry eine externe API doppelt belasten — wenn Sie zuerst arbeiten, aber Slacks HTTP-Timeout überschreiten, wiederholt Slack ebenfalls. Halten Sie ACKs schnell, schieben Sie schwere Arbeit in eine Queue, und loggen Sie den Header X-Slack-Retry-Num, falls vorhanden, damit Betreiber Erstzustellung und Replays trennen können.

Nach jeder Secret-Rotation Gateway per Unit neu starten, prüfen ob der Prozess die neue Umgebung geerbt hat, und ein Test-Event aus der Slack-Entwicklerkonsole erneut senden. Wenn die Verifikation klappt, Live-Nachrichten aber stocken, OAuth-Scopes und Kanal-Mitgliedschaft prüfen — Event Subscriptions feuern nur dort, wo der Bot mit passenden granularen Scopes wirklich anwesend ist.