2026 OpenClaw — configuration des canaux
Slack, Discord et Telegram : permissions, OAuth et triage « connecté mais silencieux »

Six symptômes de canaux qui semblent « connectés » mais restent inertes

Les problèmes de canaux sont souvent classés à tort sous « le modèle est cassé » ou « encore le réseau compose ». Avant de changer d’images ou de network_mode, étiquetez le comportement avec la liste ci-dessous et comparez-la au tableau du triage réseau Docker, afin que deux changements parallèles n’effacent pas la cause racine.

1. Événements entrants manquants : l’interface d’administration affiche en ligne, mais les nouveaux messages de canal ne produisent aucune ligne de journal Gateway — en général abonnements aux événements Slack désactivés, intents Discord Gateway absents ou mode confidentialité Telegram bloquant les groupes.
2. MP seulement, pas de canaux : les scopes OAuth ou les politiques d’adhésion du bot ne couvrent que les MP ; les messages de canal sont ignorés silencieusement — vérifiez les listes de canaux et l’appartenance du bot.
3. Analyse des commandes mais jamais de réponse : les journaux entrants existent ; les réponses sont bloquées par groupPolicy, des règles de fil ou des politiques « mention uniquement » — souvent routées vers un agent vide ou refus de permission.
4. OAuth ou jetons intermittents : tout est vert dans la console, puis rouge quelques heures plus tard — en général jetons de rafraîchissement non réécrits dans le magasin de secrets ou conteneurs redémarrés sans le même montage .env.
5. Câblage croisé workspace ou guilde : un processus lie plusieurs espaces Slack ou serveurs Discord ; des configurations fusionnées routent les rappels vers une mauvaise URL.
6. Fausse attribution au modèle : les canaux sont sains mais des réponses 429 ou 5xx en amont font croire que le bot est mort — inspectez le ratio des journaux Gateway et fournisseur et revenez à l’article sur le failover fournisseur.

Consignez ces six classes avec les modifications récentes de allowedOrigins et les déploiements d’images sur le même ticket de changement, pour que l’astreinte choisisse une branche en moins de cinq minutes.

Tableau 1 : triage en trois couches — Gateway, canaux ou modèle en premier ?

Cette matrice décide quelle couche inspecter en premier ; elle n’est pas exclusive. Chaque ligne doit correspondre à une commande concrète ou un mot-clé de journal. Esquissez trois colonnes sur papier : symptôme visible côté utilisateur, première anomalie dans les journaux Gateway, codes HTTP du modèle en amont. Si la colonne du milieu reste vide, suspendez toute modification des fournisseurs ; si la colonne de droite montre d’abord des 429, réautoriser OAuth dix fois ne réglera pas la facturation.

Avec l’article réseau Docker, traitez les sondes de canaux en échec dans le conteneur comme une couche 0 : confirmez que le CLI atteint Gateway sur le même réseau compose avant d’utiliser ce tableau ; sinon la console des webhooks Slack paraît saine alors que l’hôte ne voit que des délais d’attente.

Trois indicateurs de canaux à mettre sur un tableau de bord

Ces métriques transforment « le bot semble bloqué » en chiffres alertables ; alignez les noms de champs sur la journalisation Gateway. Préférez des agrégats horaires au bruit seconde par seconde, pour que les astreintes de nuit restent exploitables.

1. Taux d’événements entrants (IER) : événements confirmés par le canal divisés par les envois métier sur la fenêtre ; durablement sous 0,9, cela pointe vers OAuth et les abonnements, pas les GPU.
2. Taux de succès de routage (RHR) : part du trafic entrant lié à l’agent prévu ; si l’IER est bon mais le RHR chute, les politiques ou les cartes de canaux se sont dégradées.
3. Taux d’achèvement des réponses (RCR) : succès de bout en bout de l’entrant au HTTP 200 du modèle ; si l’IER et le RHR sont élevés mais le RCR est bas, priorisez la couche modèle.

La documentation communautaire en 2026 insiste encore sur openclaw channels status --probe ; tracez les résultats des sondes à côté de ces trois taux pour éviter des correctifs « reconnexion et espoir » non reproductibles. Si vous avez déjà configuré des sondes HTTP à partir de l’article health-check Gateway, assurez-vous que les URL de sondes suivent le même chemin de proxy inverse que les vrais rappels de canaux — des sondes loopback uniquement avec des rappels publics sur une autre chaîne de certificats créent des moniteurs tout verts et des utilisateurs tout rouges.

Ajoutez une habitude de réconciliation manuelle : chaque semaine, échantillonnez dix messages utilisateur et vérifiez que l’identifiant de message plateforme, l’identifiant de requête Gateway et l’identifiant de trace modèle apparaissent dans les journaux ; des liens manquants signifient une journalisation structurée défaillante — corrigez les champs avant de monter en charge.

Runbook en six étapes : des sondes aux changements OAuth réversibles

1. Geler le rayon d’explosion : capturez les tags d’image, les empreintes d’environnement et les trois derniers changements compose — les régressions de canaux arrivent souvent avec les mises en production progressives. Si allowedOrigins ou les certificats TLS ont changé le même jour, documentez le retour au fingerprint de certificat précédent pour que les rappels OAuth et CORS ne tombent pas ensemble.
2. Établir une base Gateway : confirmez que gateway status sur l’hôte ou dans le conteneur correspond au guide doctor. Avec systemd ou launchd, vérifiez les politiques de redémarrage — des redémarrages rapides déclenchent les limites de débit des WebSockets côté plateforme.
3. Autoriser par plateforme : Slack, relancer OAuth et les scopes ; Discord, activer les intents et réinviter le bot ; Telegram, ajuster la confidentialité via BotFather ou garantir les @ dans les groupes. Après autorisation, attendez le TTL de cache plateforme (souvent 5 à 15 minutes) ; évitez dix tentatives de réautorisation d’affilée.
4. Prouver un dialogue minimal : un canal, un agent, aucune politique supplémentaire pour un test ping-pong, puis réactivez groupPolicy. Préfixez les messages de test pour des journaux grep-friendly plutôt que du bruit dans des canaux publics.
5. Contraster la couche modèle : si le ping-pong échoue encore, échantillonnez 30 secondes de journaux pour la part de 429 avant de changer de fournisseur. Si les 429 se concentrent sur une clé, vérifiez si des clés grand public ont été mélangées avec des clés à l’usage.
6. Réécrire le runbook : stockez la rotation des jetons et les chemins de secrets dans le même dépôt que les notes réseau Docker pour qu’un seul poste ne détienne pas les releases. Donnez aux collaborateurs des scopes lecture minimaux ; gardez les clés maîtresses dans un KMS ou des secrets scellés.

Slack, Discord et Telegram : contrôles rapides sur une page

Exécutez-les dans chaque console fournisseur ; ne vous fiez pas à d’anciennes captures. Si vous maintenez des espaces de staging et de production, ajoutez une colonne dédiée pour les noms d’hôte de rappel, afin que les certificats de staging ne se lient jamais au DNS de production.

• Slack : jetons au niveau application et bot tous valides ; les URL d’abonnement aux événements pointent vers le Gateway public réellement exécuté ; le mode socket n’est pas mélangé avec HTTP par inadvertance. Sur Enterprise Grid, vérifiez que chaque installation d’espace de travail référence le même client OAuth, sinon certaines régions ne recevront jamais d’événements.
• Discord : l’intent Message Content et l’intent Server Members correspondent aux besoins réels ; le bot est visible dans les canaux cibles ; les dérogations de canal n’interdisent pas l’envoi. Utilisez les diagnostics de permissions Discord plutôt que de ne lire que les noms de rôles.
• Telegram : webhook ou long polling — choisissez l’un ou l’autre ; les certificats et les URL de rappel ne doivent pas dériver après des mises en production progressives ; les groupes peuvent exiger des mentions explicites sous mode confidentialité. Les certificats auto-signés doivent toujours exposer les ports et versions TLS attendus par Telegram ; faites tourner les certificats dans leur propre fenêtre de changement.

Les trois plateformes sont sensibles aux adresses IP de sortie stables. Le haut débit résidentiel ou les VPN qui changent de nœud de sortie ressemblent à du trafic webhook abusif. Cela rejoint les recommandations Mac cloud multi-régions sur des régions fixes et une sortie auditable — déplacez le plan de contrôle vers un hôte dont l’atteignabilité est démontrable avant que l’équipe dépende du bot.

Pourquoi un portable personnel ne peut pas porter des canaux OpenClaw à l’échelle d’une équipe

La mise en veille, les VPN et les proxys locaux modifient les IP de sortie et les empreintes TLS, ce qui fait échouer aléatoirement les rappels OAuth et les listes autorisées côté fournisseur. Les portables partagés ne centralisent pas non plus la rotation des jetons ni les champs d’audit. Exécutez Gateway et les workers de canaux sur un plan de sortie stable et joignable en astreinte pour rester aligné avec les politiques d’agents d’équipe.

Pour les topologies qui exigent un service toujours actif, des domaines de rappel fixes et une sortie prévisible, MACCOME propose des Mac mini M4 / M4 Pro hébergés dans le cloud à Singapour, au Japon, en Corée, à Hong Kong, sur la côte est et la côte ouest des États-Unis — adaptés à Gateway et à la chaîne d’outils Apple. Après le triage des canaux, croisez avec le guide SSH contre VNC et le centre d’aide location Mac mini, puis finalisez sur les tarifs publics de location et les pages régionales.

Schéma pilote : faites tourner 24 heures d’IER et de RCR sur un hôte de test dédié avec un seul canal avant d’ouvrir un espace de production — évitez d’activer une grande communauté et de passer au rouge instantanément.