Migration de la flotte OpenClaw 2.0 : ce qui a réellement cassé

Mettre à niveau une seule instance OpenClaw est une chose, mais le faire pour une flotte de clients en direct signifie que chaque panne se multiplie. Une équipe a passé une journée entière à migrer vers OpenClaw 2.0 et a partagé les angles les plus tranchants. Voici ce qui a réellement cassé et comment l'éviter.

Le schéma de configuration est devenu plus strict

Dans la version 2.0, le schéma de configuration est plus strict et plusieurs champs ont été déplacés (clés d'environnement, TTS, modèles média). Le piège le plus important : doctor --fix supprime silencieusement les champs inconnus. Si votre clé de modèle se trouve dans une zone désormais obsolète, elle peut disparaître avec ces champs. L'équipe a réécrit les configurations à la main avant d'exécuter doctor pour éviter de perdre des clés.

Les plugins externes cassent la passerelle

WhatsApp, Brave, Discord et Perplexity ne sont plus dans l'image de base ; ce sont des plugins externes. Si votre configuration les référence encore, la passerelle ne devient jamais prête, le conteneur entre dans une boucle de redémarrage, et de l'extérieur cela ressemble à une erreur 502. Ajouter simplement les plugins à l'image ne suffit pas car le consentement des capacités est lié à la machine spécifique, et doctor ne l'accepte pas. La seule approche qui fonctionne est d'exécuter openclaw plugins install ... --accept-capabilities comme étape séparée.

Appairage des appareils : les en-têtes Cloudflare cassent la localité

Le chat web a commencé à générer PAIRING_REQUIRED. La cause racine : la version 2.0 ne fait confiance qu'aux requêtes provenant de loopback sans aucun en-tête transféré. Ne pas les définir dans nginx ne suffit pas — Cloudflare envoie ses propres en-têtes, il faut donc les annuler explicitement dans nginx. Cela ressemblait à un jeton cassé mais c'était en réalité un conflit entre Cloudflare, nginx et la logique de localité d'OpenClaw.

Perplexity se charge automatiquement de manière indésirable

Perplexity se charge automatiquement s'il détecte une clé OpenRouter, puis exige un consentement même si vous ne voulez pas du plugin. Définir enabled: false ne suffit pas ; vous devez utiliser plugins.deny pour le bloquer.

Leçon : privilégier la disponibilité aux fonctionnalités

Le principe final : il vaut mieux perdre temporairement la recherche web ou un canal unique que de faire tomber tout l'agent avec une erreur 502. Prévoyez plusieurs pannes et testez chaque composant individuellement.

Ceci est basé sur un rapport de migration réel provenant d'une plateforme cloud hébergeant OpenClaw pour des clients. Si vous planifiez une mise à niveau, lisez la source pour plus de détails et d'informations de la communauté.