2026 OpenClaw MeshMac : passerelle partagée, rate limit et plafond de sessions — runbook minimal multi-nœuds

Une passerelle partagée concentre l'écoute HTTP, les webhooks entrants, les sessions longues des agents sur chaque Mac et parfois des callbacks workers. Sans budget publié, ces flux s'additionnent : dix nœuds avec deux jobs concurrents peuvent ouvrir vingt sessions vers le même processus, même si la file amont reste saine. La collaboration exige donc un modèle de capacité partagé (requêtes par seconde et sessions max), des limiteurs identiques sur chaque réplique derrière le VIP, et des plafonds miroir côté CI et messagerie. Où accrocher les modules HTTP de limitation ? La matrice Nginx versus Caddy pour l'entrée TLS aide à choisir la bordure et les hooks limit_req ou équivalents sans sacrifier WebSocket.

1. Absence de budgets : saturation silencieuse puis timeouts côté client qui relancent en boucle.
2. Identités instables : une clé API partagée empêche d'isoler un voisin bruyant.
3. Retries non bornés : la file accepte trop de travail toxique ; préférez rejeter tôt au bord, comme dans file de tâches et politique de retry MeshMac.

1. Inventaire des routes. Classez chaque chemin en interactif, ingestion_ci ou worker_interne ; ce libellé devient route_class dans les logs.
2. Choix des identités. Clé API, sujet OAuth, en-tête tenant_id injecté par CI, ou IP seulement en dernier recours.
3. Deux nombres par classe. Débit soutenu après rafale autorisée (seau de jetons) et nombre maximal de sessions ou connexions TCP simultanées (sémaphore).
4. Interaction avec la file. Le contrôle d'admission passerelle doit rester plus strict que la croissance de profondeur broker : rejeter à l'entrée coûte moins cher que dépiler du poison.
5. Rollout en mode observation. Pendant une release, comptabilisez les refus potentiels sans renvoyer 429 ; activez l'application et surveillez la latence p95.
6. Accord d'équipe. Documentez les chiffres dans le runbook partagé du pool et validez-les après chaque changement de taille de maillage.

Le seau de jetons lisse les rafales HTTP : recharge à un taux r, rafale maximale B. Il protège contre les vingt POST webhook en une seconde tout en préservant le débit moyen. Le plafond de sessions borne les flux TLS longue durée, WebSocket ou sessions agent coûteuses en mémoire. En production vous combinez presque toujours les deux : jetons pour les arrivées, sémaphore pour le travail parallèle cher.

Repères exploitables : viser une corrélation systématique entre limiteur et étiquettes CI (mesh_node_id) ; conserver quatorze jours de logs JSON pour post-mortem ; revoir les seuils après chaque ajout de nœud au pool.

Des limiteurs passerelle sans discipline amont restent inefficaces. Côté GitHub Actions, groupez la concurrency par environnement pour qu'un seul déploiement parle à la passerelle à la fois, et réduisez le parallélisme de matrice pour éviter que chaque job n'ouvre sa session. Pour Matrix, Teams ou autres connecteurs, traitez les tentatives de retry comme un second seau : une salle avec plusieurs bots multiplie le trafic si chaque bot ignore le budget global. Les messages par minute se superposent au débit HTTP ; calibrez-les ensemble. Lors du préchauffage des skills sur les nœuds, espacez les vagues pour qu'elles ne coïncident pas avec une réouverture massive de sessions après incident.

Exposez un /healthz peu coûteux qui agrège disque, ping file et dépendances critiques. Lorsque la sonde fusionnée échoue ou que la latence dépasse le SLO, basculez un drapeau interne : répondez 503 avec Retry-After pour les nouvelles sessions tout en laissant finir ou drainer le travail en cours avec un délai court. Vous pouvez resserrer automatiquement le refill des jetons lorsque le CPU dépasse quatre-vingts pour cent pendant plusieurs secondes, puis relâcher après une période de calme. Le répartiteur doit réutiliser la même sonde pour retirer les réplicas malades avant fusion complète.

Les opérateurs doivent pouvoir agréger une ligne JSON par refus ou shedding sur l'ensemble du maillage.

Alertez sur un ratio 429 soutenu par locataire (mauvaise config amont) et sur des pics 503 corrélés à une santé rouge (incident capacité ou dépendance). Complétez par des traces pour séparer « limité au bord » et « timeout worker ».

En synthèse : une passerelle OpenClaw sur MeshMac mutualisée exige des plafonds explicites, un alignement CI et messagerie, et des journaux stables pour le diagnostic multi-nœuds. Poursuivez sur le hub thématique OpenClaw et l'index du blog pour les playbooks adjacents.