Lorsque la passerelle OpenClaw tourne en continu sur un VPS Linux, la majorité des incidents ne ressemblent pas à un bug de compilateur mystérieux : ce sont surtout l'état du processus, le signal dans les journaux et l'accessibilité des ports, examinés dans le mauvais ordre. Ce billet fixe la même trame par paliers que nous utilisons après l'onboarding et le durcissement HTTPS, pour que l'astreinte arrête de deviner si la faute vient de systemd, de l'application, du pare-feu ou du reverse proxy devant le service.
Palier 0 : contrôle de réalité en deux minutes
Vérifiez que la machine est bien celle visée (hostname, tag d'image, dernier déploiement), puis répondez à trois questions : l'unité est-elle censée tourner ? Tourne-t-elle réellement ? Quelque chose écoute-t-il sur le port loopback attendu ? Si l'une des réponses est « non », restez au palier 0 avant d'ouvrir un ticket TLS ou DNS.
| Palier | Objectif | Outils principaux |
|---|---|---|
| 0 | Séparer « hôte HS » de « appli mal configurée » | uptime, systemctl is-active, ss -lntp |
| 1 | Comprendre pourquoi le démon s'arrête ou oscille | journalctl -u …, openclaw logs (flags follow/tail selon votre build) |
| 2 | Prouver le chemin client → socket lié | curl -v vers la boucle locale, puis URL de bord, traces pare-feu / Nginx / Caddy |
doctor / fix, reverse proxy TLS et rollback — voir notre check-list Linux. En savoir plus : 2026 — OpenClaw Gateway en production sur Linux : openclaw onboard, openclaw doctor / openclaw fix, HTTPS Nginx ou Caddy, montée de version et rollback.
systemd et le démon passerelle
Corrélez toujours codes de sortie et politique de redémarrage. Un service qui boucle sous Restart=on-failure noie les journaux utiles tant que vous n'élargissez pas la fenêtre journald et ne figez pas les modifications de config. Capturez une fenêtre d'échec propre : lignes de statut, les cinquante dernières lignes de log, et si ExecStart pointe bien vers le binaire mis à jour hier.
# Remplacez openclaw-gateway par le nom livré chez vous
systemctl status openclaw-gateway --no-pager -l
journalctl -u openclaw-gateway -b --no-pager -n 120
Si le statut reste « activating » indéfiniment, suspectez plutôt un fichier d'environnement manquant, un mauvais répertoire de travail ou une chute de capabilities après upgrade noyau — pas le pont de chat. Épinglez une unité connue bonne dans le dépôt Git à côté de votre compose ou script d'install : le rollback devient systemctl daemon-reload plus un remplacement de fichier, pas une fouille dans /etc.
systemctl is-active.
Journaux openclaw sans noyer l'équipe
Chaque invocation CLI de logs doit répondre à une question : amorçage (la config parse-t-elle ?), exécution (quelle route a échoué ?) ou intégration (quel jeton ou canal a refusé ?). Faites tourner les fichiers ou limitez journald avant d'activer le trace complet — sinon le disque du VPS devient l'incident. Pour corréler avec journalctl, collez les horodatages en UTC afin d'éviter le « c'était à 9h » ambigu entre fuseaux.
# Exemple — adaptez les sous-commandes à votre CLI installée
openclaw logs --since 30m
journalctl -u openclaw-gateway --since "30 min ago" --no-pager | tail -n 80
Sondes de port passerelle : boucle locale d'abord, bord ensuite
Sondez 127.0.0.1 (ou l'adresse de bind explicite de la config) avant de tester le nom public. Si la boucle locale échoue, aucun Cloudflare ni débogage ACME ne sauvera la situation. Si la boucle locale réussit mais le bord échoue, remontez la chaîne : adresse de bind (0.0.0.0 vs 127.0.0.1), ufw / nftables, groupes de sécurité, puis le bloc upstream du reverse proxy.
curl -svS http://127.0.0.1:18789/health # port/chemin d'exemple
curl -svS https://gateway.exemple.com/health
Des erreurs TLS sur l'URL publique alors que la boucle locale en HTTP clair fonctionne indiquent souvent un proxy qui parle HTTP/2 là où l'amont attend HTTP/1.1, ou un mauvais SNI — une capture curl -v vaut mieux qu'une capture d'écran du navigateur.
FAQ : faux positifs fréquents en 2026
« Port fermé » depuis l'extérieur alors que ss affiche LISTEN — vérifiez le groupe de sécurité côté client et si la passerelle n'écoute que la loopback. 502 après upgrade — chemin de socket obsolète ou permissions de socket Unix modifiées ; lisez les notes de version avant d'empiler des overrides systemd. Auth qui tombe d'un coup — permissions de fichier de jeton après un chmod automatisé ; le propriétaire doit correspondre à l'utilisateur du service.
Quand la pression release monte, séparer la disponibilité de la passerelle Linux de la capacité de build macOS clarifie les responsabilités : beaucoup d'équipes associent un petit VPS toujours allumé pour OpenClaw à des runners Mac cloud à la demande. Les différences de persistance entre launchd sur Mac et systemd sur Linux sont résumées ici : Déployer OpenClaw sur un Mac cloud en 2026 : validations macOS face à un VPS Linux, persistance launchd et FAQ de dépannage reproductible.
Passerelle sur Linux, builds sur le Mac cloud
Un VPS Linux léger convient bien aux passerelles et bots toujours actifs : IP fixe, systemd prévisible et faible consommation au repos. L'autre moitié du pipeline — Xcode, signature, pics CI — reste plus confortable sur du matériel Apple réel. Un Mac mini M4 cloud chez VPSSpark combine environnement Unix familier et macOS natif : Homebrew, SSH et conteneurs sans la friction habituelle des postes Windows, avec une mémoire unifiée Apple Silicon qui évite que les étapes de linkage ne saturent trop tôt.
La stabilité de macOS, Gatekeeper et SIP réduisent le risque de « casse du vendredi soir » par rapport à des fermes de build Windows ad hoc, et une consommation idle d'environ 4W sur M4 Mac mini rend un runner permanent économiquement raisonnable à côté de votre facture VPS.
Si vous séparez passerelle Linux et builds Mac, le Mac mini M4 cloud VPSSpark relie proprement les deux mondes — découvrez les offres maintenant et gardez les deux bords de la stack sous contrôle.