2026 — OpenClaw et Slack sur VPS Linux cloud : jetons de bot, abonnements aux événements, URL de callback vers la passerelle — déploiement reproductible et FAQ 403 / rejeu par niveaux

Les abonnements aux événements Slack exigent un point de terminaison HTTPS stable, des signatures vérifiables et des réponses JSON rapides. Lorsque la passerelle OpenClaw tourne sur un petit VPS Linux, la plupart des incidents ne viennent pas de Slack : ce sont des fronts TLS, des chemins qui ne correspondent pas entre l’app Slack et le reverse proxy, ou des couches d’auth qui renvoient 403 avant même la vérification du secret de signature. Partez d’une base reproductible (installation, adresses d’écoute, TLS), alignez jetons et URL de callback comme pour d’autres surfaces de chat — voir OpenClaw 2026 comme serveur MCP dans le flux de développement : de openclaw mcp serve aux jetons, listes blanches d’outils et isolation de session pour la discipline des jetons — et gardez le découpage Linux / poste opérateur explicite avec Déployer OpenClaw sur un Mac cloud en 2026 : validations macOS face à un VPS Linux, persistance launchd et FAQ de dépannage reproductible.

Ce que Slack attend sur le fil

Créez ou réutilisez une app Slack, activez les abonnements aux événements et collez une URL de requête vers votre VPS sur le port 443. Slack envoie d’abord url_verification ; la pile doit renvoyer le JSON de challenge en quelques secondes sans bufferiser le corps deux fois. Ensuite Slack livre des enveloppes avec X-Slack-Signature et X-Slack-Request-Timestamp. Le secret de signature appartient à un SecretRef ou un fichier lisible uniquement par l’utilisateur de la Gateway — jamais dans Git, jamais en /etc lisible par tous. Les jetons de bot (xoxb-) alimentent les appels Web API (réponses, etc.) : limitez les scopes aux canaux et méthodes réellement utilisés pour qu’une fuite ne balaye pas tout l’espace de travail.

URL de callback → bord TLS → Gateway en loopback

Liez la Gateway sur 127.0.0.1 au port documenté dans votre config OpenClaw, terminez le TLS avec Nginx ou Caddy, et proxifiez les POST ainsi que les upgrades WebSocket si votre surface de contrôle en a besoin. Le chemin public dans Slack (par ex. /slack/events) doit correspondre au bloc location qui termine le TLS : un slash de trop ou un double préfixe (/openclaw/slack/slack/events) suffit pour que Slack voie un 403 du proxy alors qu’un curl vers le loopback reste « vert ». Journalisez le statut amont séparément du processus Gateway pour savoir si le bord a répondu avant que le worker Node ne s’exécute.

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

Commandes slash, raccourcis et URL d’interactivité

Les abonnements aux événements ne sont qu’une entrée parmi d’autres. Commandes slash, raccourcis et interactivité Block Kit déclarent chacune leur propre URL dans les réglages de l’app ; chacune doit atteindre le même bord TLS avec la même discipline de chemins. Si les événements pointent vers OpenClaw mais l’interactivité reste sur un ancien tunnel, vous obtenez des « boutons morts » alors que les MP arrivent encore — piège classique après migration. Gardez tous les callbacks sur le même certificat et la même chaîne de logs pour réutiliser une requête journal lors des chasses au 403.

Check-list reproductible (VPS Linux)

Provisionnez Ubuntu LTS ou Debian 12, installez OpenClaw sur le canal que l’équipe fige en production, et faites l’onboarding une fois depuis un shell UTF-8 avec un utilisateur UNIX dédié. Ouvrez 22/tcp seulement depuis les IP d’admin, 80/443 depuis Internet pour ACME et les callbacks Slack, et gardez le port Gateway hors 0.0.0.0/0. Quand openclaw gateway status montre l’écoute loopback, émettez les certificats, rechargez le proxy, puis seulement activez l’interrupteur Slack. Snapshottez ~/.openclaw et l’espace de travail avant de faire tourner les secrets : le rollback doit être « restauration d’archive + reload unit », pas de l’archéologie.

FAQ 403 par niveaux, rejeu et livraisons en double

Lors du débogage, descendez la pile dans l’ordre — chaque niveau laisse une empreinte différente dans les journaux d’accès et d’application.

Slack peut réessayer la livraison : rendez les gestionnaires idempotents sur event_id (ou des clés de déduplication déterministes). Si vous acquittez avant la fin des effets de bord, un rejeu peut doubler un appel API externe ; si vous terminez le travail d’abord mais dépassez le délai HTTP de Slack, Slack réessaiera aussi. Gardez les acquittements rapides, poussez le lourd vers une file, et journalisez X-Slack-Retry-Num quand il est présent pour distinguer première livraison et rejeux.

Après toute rotation de secret, redémarrez la Gateway via l’unit systemd, vérifiez que le processus a bien hérité du nouvel environnement, et renvoyez un événement test depuis l’UI développeur Slack. Si la vérification passe mais les messages réels s’arrêtent, revérifiez les scopes OAuth et la présence du bot dans le canal — les abonnements aux événements ne tirent que là où le bot est réellement présent avec les bons scopes granulaires.