01. Triage : binds 0.0.0.0, pas de superviseur, mauvais en-têtes proxy

1) Écoute sur toutes les interfaces par défaut. Les tutoriels rapides qui exposent le plan de contrôle à Internet vont en labo ; sur un VPS public c’est négligent. Préférez 127.0.0.1 pour le processus Gateway et laissez le reverse proxy prendre le 443. Jetons et SecretRef multi-nœuds relèvent de le guide passerelle distante—ne dupliquez pas les secrets dans l’historique shell.

2) Sessions SSH longues jouant les ops. Si la passerelle meurt quand vous fermez le portable, ce n’est pas un service—c’est une démo. systemd offre politiques de restart, ordre des dépendances (après network-online) et journaux structurés sans taxe Kubernetes.

3) Reverse proxies sans conscience WebSocket. Clusters de symptômes : 502 intermittents, canaux qui se connectent sans répondre, tempêtes de reconnexion ressemblant à une panne modèle alors que ce sont des défauts de proxy_read_timeout. Corrigez le bord avant de brûler des crédits API.

Pourquoi les post-mortems se répètent ? Parce qu’on confond joignabilité LAN et surface d’attaque publique. Une API d’administration sur 0.0.0.0 suffit à attirer des campagnes automatisées après un index Shodan. Architecturalement la réponse est simple : lier, filtrer, terminer. En pratique on échoue sur des snippets Nginx copiés-collés sans revue ni test de charge WebSocket.

tmux survive aux coupures SSH mais n’applique ni backoff de restart ni dépendances réseau déclaratives. systemd mappe ces besoins sur des fichiers unit versionnés dans Git—indispensable si vous voulez oublier la machine pendant des mois tout en gardant la conformité.

La terminaison TLS n’est pas que des certificats : elle fixe les en-têtes visibles par l’app, la durée de vie amont et la fragmentation WebSocket. Les symptômes ressemblent à « le modèle répond au hasard » alors que l’API d’inférence est verte. Collectez des logs proxy horodatés avant d’ouvrir un ticket fournisseur.

Dans les clouds européens, facturation egress et groupes de sécurité stricts amplifient le coût des mauvais listeners. Plus le processus Gateway est serré sur la loopback, moins le bruit de scan pollue votre monitoring—et moins l’astreinte perd de temps sur des alertes non actionnables.

02. systemd vs Docker vs Kubernetes

Voie	Idéal pour	Coût	Cet article
systemd + npm/binaire nu	VPS unique, minimum de pièces mobiles	Vous possédez les units et runbooks de montée de version	Focus principal
Docker	Versions reproductibles staging/prod	Chaîne d’images, volumes, réseau	Voir guide sécurité Docker cinq étapes
Kubernetes	Répliques élastiques, équipes plateforme existantes	Opérateurs, politiques, certs à grande échelle	Docs cluster ; pas interchangeable avec un VPS seul

Docker apporte la reproductibilité mais empile des couches NAT qui compliquent le debug quand hôte et conteneur écoutent tous deux. Pour une équipe avec CI, l’investissement se paie ; pour une personne sur petit VPS, souvent non. Kubernetes amplifie : sidecars et NetworkPolicies ne remplacent pas une histoire claire d’injection de secrets.

Si vous appliquez déjà la série Docker, transposez rootfs en lecture seule, namespaces utilisateur et scans de build vers les images Gateway. Sur systemd, AppArmor ou NoNewPrivileges=yes jouent un rôle comparable lorsqu’ils sont documentés.

Les déploiements hybrides—passerelle sur VPS, nœuds macOS loués—exigent des noms SecretRef cohérents entre dépôts. Sinon le staging passe et la prod casse car les chemins du coffre diffèrent. Préfixez explicitement l’environnement dans les chemins secrets et reflétez-le dans votre stratégie de templates openclaw.json.

03. Pare-feu & listeners de référence

Ouvrez seulement 22, 80, 443 (80 optionnel pour ACME HTTP-01). Le port d’administration Gateway ne doit pas apparaître sur 0.0.0.0 dans ss -lntp. Port de debug temporaire : listes blanches IP source ou WireGuard, fermeture dans le même ticket.

Contrôle	Cible	Symptôme si faux
Adresse de bind Gateway	127.0.0.1 + port local documenté	API de contrôle indexables par scan
En-têtes upgrade proxy	Timeouts compatibles WebSocket	Échecs silencieux de canaux, clients instables
Automatisation TLS	Let’s Encrypt + renouvellement surveillé	Mobile rejette certificats périmés/auto-signés

Les fournisseurs cloud divergent sur les groupes de sécurité par défaut. Documentez règles entrantes et sortantes (DNS, OCSP, APIs). Cas classique : Nginx parfait mais ACME bloqué car egress 443 interdit—rare mais coûteux en temps de debug.

Hebdomadairement, différenciez ss -lntp par rapport à la baseline. Automatisez un ticket si des processus inattendus apparaissent. Vous détecterez aussi des processus Node orphelins après échec de déploiement.

Documentez quel utilisateur Unix possède le Gateway et quelles capabilities systemd accorde. Des permissions trop larges sur ~/.openclaw équivalent à un port ouvert pour toute énumération locale.

04. Sept étapes jusqu’au TLS public

Baseline OS : mises à jour sécurité ; curl, git, ca-certificates ; Node selon la matrice du guide d’installation.
Installer la CLI : script officiel ou un npm global—ne pas mélanger npm, pnpm et tarballs sans documenter le gagnant de which openclaw.
Onboard : matérialiser ~/.openclaw/openclaw.json ; clés via SecretRef comme dans la doc passerelle.
Forcer loopback : vérifier avec ss -lntp après démarrage ; seul le proxy face au WAN.
Enregistrer systemd : openclaw gateway install si dispo, sinon unité avec Restart=on-failure et StartLimitIntervalSec raisonnable.
Nginx ou Caddy : certificats, HSTS délibéré, timeouts read/send pour connexions longues.
Fumée externe : curl via hostname public, sondes canaux, journaux masqués dans le ticket.

# Santé du service (nom d’unité variable)
systemctl status openclaw-gateway.service
journalctl -u openclaw-gateway.service -n 200 --no-pager

Ajoutez un test canari depuis un second réseau (4G, bureau) dans la même liste de changement. Beaucoup de problèmes TLS n’apparaissent qu’avec inspection SSL d’entreprise. Sans cela vous croyez à tort que le cutover est vert.

Versionnez les snippets proxy dans Git et citez le commit dans le ticket. Rollback : vous savez quels blocs location restaurer sans diff paniqué sur la prod.

05. Échelle de triage & métriques

Suivez l’échelle ; dans les incidents collez des résumés—pas les secrets complets :

openclaw status
openclaw gateway status
openclaw logs --follow ou journalctl
openclaw doctor / openclaw doctor --fix
openclaw channels status --probe

Correspondance de chaînes avec la FAQ commandes économise des heures quand la dérive JSON5 ou l’ABI plugin imite une panne réseau.

Métrique 1 : Environ 28%–41% des incidents Gateway première semaine viennent d’une mauvaise config listener/pare-feu plutôt que des APIs modèle (rétros internes).
Métrique 2 : Après bind 127.0.0.1 et exposition du seul 443, le bruit de scan baisse souvent de 60%–85% selon le bruit de fond du fournisseur.
Métrique 3 : Sans rotation des logs, 18%–27% des petits VPS ont rempli le journal en 7–14 jours—plafonner ou expédier les logs.

Ce sont des ordres de grandeur, pas des SLA. Servez-vous-en comme lignes de tableau de bord : dépassement ⇒ vérifier d’abord réseau et disque. Ajoutez un journal de temps par étape pour enrichir les post-mortems.

Si doctor --fix est utilisé, faites-le en fenêtre de maintenance avec snapshot des fichiers de config. Pratique mais risqué sans sauvegarde quand plusieurs plugins migrent ensemble.

06. Journaux, rotation, discipline SecretRef

Traitez openclaw.json comme infra-as-code : PR, reviewers, SecretRef plutôt que jetons collés dans le chat. Runbooks de rotation avec chevauchement de credentials, horodatage de bascule, sondes de vérif. Équipes Docker intègrent les mêmes contrôles en pipeline selon le guide Docker.

Avant grosses montées de version, répétez sur matériel jetable. Sans Mac local : location macOS journalière pour valider puis promouvoir vers le VPS. Drills trimestriels : reconstruire depuis coffre + units en moins d’une heure.

Observabilité : exportez santé minimale (processus up, dernière sonde canal OK)—même un cron curl bat le tirage au sort. Corrélez redémarrages Gateway et OOM ; petits VPS : swap prudent face aux pics de tas Node lors du fan-out.

Gestion du changement : étiquetez la prod openclaw.json avec un SHA Git ou commentaire de version. Rollback : conserver l’unité précédente et la version npm épinglée à côté de l’entrée de coffre.

SecretRef est un contrat entre dépôt et backend de secrets. La CI doit échouer sur chemins invalides, pas l’astreinte du dimanche. Jetons Gateway à courte durée et phases de chevauchement documentées réduisent les temps d’arrêt.

Paramétrez SystemMaxUse= pour journald ou expédiez les logs JSON vers stockage objet. Disque racine plein en plein fan-out déclenche souvent des boucles de crash ressemblant à des bugs applicatifs.

07. Arbitrages & quand louer macOS pour répéter

Passerelle sur portable tient jusqu’à ce que sommeil, Wi‑Fi itinérant et DNS dynamique ruinent la disponibilité. WSL2/devcontainers aident les devs mais sont maladroits comme point d’Internet souverain. VPS Linux + systemd équilibre SSH, TLS standard et facturation prévisible pour un solo.

macOS reste le confort pour debug GUI, Safari et proximité toolchain Apple. Louer du Mac réduit le risque capital tout en gardant l’outillage natif. Capacité sur la page tarification et connectivité dans le guide d’accès à distance lorsque vous ajoutez de la répétition à côté du VPS.

Économiquement : Mac dédié coûte CAPEX/énergie ; VPS est fixe mensuel ; location journalière ne facture que les heures Xcode/Safari. Combinez présence VPS + macOS loué pour régressions majeures.

À long terme, les runbooks qui lient units, fichiers proxy et JSON OpenClaw dans un seul changeset gagnent. Les retours arrière deviennent des revert Git plutôt que des procédures semi-manuelles oubliées.

Un drill chaos trimestriel—perdre SSH, ne reconstruire que via console OOB et vos étapes documentées—révèle les trous de sauvegarde avant qu’un incident réel ne les expose sous pression.