Faire tourner OpenClaw sur un petit VPS Linux cloud tout en gardant Ollama sur une machine à la maison ou un LAN privé est un schéma fréquent en 2026 : les canaux publics et les webhooks arrivent sur le VPS, mais les poids et le GPU restent là où l’électricité et la politique interne le permettent. Les pannes viennent presque toujours du réseau, pas du modèle : mauvaise URL d’amont, TLS terminé deux fois, un HTTP_PROXY d’entreprise qui détourne le trafic loopback, ou un tunnel SSH qui tombe sans bruit après une mise en veille. Ce guide rassemble un câblage reproductible et une analyse en trois paliers pour arrêter de deviner si un 502 vient de Nginx, de la Gateway ou d’Ollama en train de charger un modèle en VRAM.
Topologie : qui possède chaque saut
Imaginez une ligne droite : navigateur ou canal messagerie → TLS sur le port 443 → reverse proxy (Caddy ou Nginx) → OpenClaw Gateway sur un port loopback → client HTTP vers Ollama. Ollama peut écouter sur le même VPS (127.0.0.1:11434), sur une IP de bridge Docker, ou sur un port renvoyé depuis chez vous via SSH. Notez cette liste sur papier avant de toucher aux configs ; dès que vous mélangez localhost dans un conteneur avec localhost sur l’hôte sans publier les ports, vous récoltez des bugs du type « ça marchait hier ».
Si la Gateway tourne dans Docker sans network_mode: host, le 127.0.0.1 du conteneur n’est pas celui du VPS : publiez le port d’Ollama ou du tunnel sur l’hôte et joignez-le via l’IP de passerelle du bridge (souvent 172.17.0.1), puis alignez NO_PROXY sur ces noms ou adresses stables — sinon des health checks « verts » dans le conteneur masquent un refus sur le loopback de l’hôte.
Amont Gateway vers Ollama
Pointez le backend modèle de la Gateway vers une seule URL de base canonique — en général http://127.0.0.1:11434 si Ollama est colocalisé, ou http://127.0.0.1:18080 si vous dédiez un port local au tunnel. Évitez une chaîne supplémentaire en HTTPS sur la machine, sauf si vous aimez le double chiffrement et les erreurs de certificat. Après chaque changement, testez /api/tags avec curl sous le même utilisateur que systemd ; si curl fonctionne mais pas la Gateway, cherchez un autre utilisateur, un autre namespace réseau ou une surcharge d’unité obsolète. Pour le TLS de prod, le rollback et l’assistant autour de la Gateway, nous gardons une checklist plus longue dans 2026 — OpenClaw Gateway en production sur Linux : openclaw onboard, openclaw doctor / openclaw fix, HTTPS Nginx ou Caddy, montée de version et rollback.
TLS : bordure publique vs HTTP interne
Ne terminez le TLS qu’au reverse proxy. Laissez Caddy ou Nginx parler HTTPS au monde et HTTP clair vers 127.0.0.1:18789 (exemple de port d’écoute Gateway). Si vous pointez le proxy vers un amont https:// en loopback, il faut maintenir des certificats pour ce saut interne avec le même rythme de renouvellement que la bordure — rarement rentable. Activez le keep-alive HTTP/1.1 vers Ollama pour le streaming ; certains modèles de proxy désactivent le buffering du flux — vérifiez que vous ne stockez pas toute la complétion avant de la renvoyer. Pour réduire l’exposition, comparez l’accès uniquement SSH au HTTPS public avec la matrice de 2026 — OpenClaw Linux, VPS cloud : surface d’attaque minimale — modèles de pare-feu, liaison Gateway en loopback et administration par tunnel SSH ; matrice face au reverse proxy HTTPS public et FAQ par paliers.
Tunnel SSH reproductible (Ollama à la maison → VPS)
Depuis une machine domestique toujours allumée qui exécute Ollama, ouvrez un reverse forward vers le VPS pour que le nuage voie Ollama comme du loopback : ssh -N -o ServerAliveInterval=30 -o ExitOnForwardFailure=yes -R 127.0.0.1:18080:127.0.0.1:11434 user@vps. Sur le VPS, pointez l’amont Gateway vers http://127.0.0.1:18080. Gardez GatewayPorts no, des clés SSH, et lancez le client sous systemd côté domicile pour que la veille ne coupe pas le tunnel. Documentez quelle extrémité possède le port 18080 avant d’ouvrir un ticket.
# Ollama joignable sur le port renvoyé curl -sS http://127.0.0.1:18080/api/tags | head # Santé Gateway après le proxy (remplacez l’hôte) curl -sS https://gw.exemple.com/healthz
NO_PROXY et dérivés (matrice)
Beaucoup d’images VPS exportent HTTP_PROXY pour les miroirs ; harmonisez majuscules et minuscules ou désactivez-les pour l’unité systemd de la Gateway. Servez-vous de la matrice lorsque Ollama doit rester sur le loopback.
| Cible | Symptôme si mal réglé | Correctif |
|---|---|---|
127.0.0.1 / localhost |
Logs Gateway : connexion proxy vers la passerelle d’entreprise ; 502 en quelques millisecondes | NO_PROXY=127.0.0.1,localhost,::1 sur l’unité systemd |
Bridge Docker (172.17.0.2) |
Timeouts intermittents quand compose change l’ordre des IP | Nom de service stable + bridge dédié ; ajoutez ce nom à NO_PROXY |
| Amont socket Unix | ECONNREFUSED malgré le fichier socket |
Alignez l’UID dans l’unité ; vérifiez qu’aucun ProxyCommand n’enveloppe les outils locaux |
read_timeout du proxy et vérifiez la marge VRAM. Un 502 instantané avec un corps minuscule signifie en général qu’aucun service n’écoute encore sur le socket amont.
Analyse en paliers : 502, blocage ou reset
Palier A — Bordure : lisez les journaux Nginx ou Caddy ; connect() failed (111: Connection refused) sur HTTPS indique qu’aucun service n’écoutait sur le port amont. Palier B — Gateway : vérifiez que l’URL sortante correspond exactement à celle utilisée par curl depuis la même unité. Palier C — Ollama : consultez les logs de chargement de modèle ; le premier jeton après un froid démarrage peut dépasser les timers de lecture par défaut du proxy. Si seuls les prompts longs échouent, suspectez les limites de corps en bordure avant d’incriminer Ollama.
curl en une ligne depuis le loopback du VPS. Cette séquence tranche la plupart des débats en un aller-retour.
Sur un Mac mini cloud, Ollama reste dans la même pièce que votre IDE
Lorsque vous itérez sur les prompts, les outils et les plugins Gateway, colocaliser Ollama avec une machine de bureau supprime la latence de queue SSH et rend le streaming quasi instantané. L’architecture mémoire unifiée d’Apple Silicon accueille bien les modèles moyens qui feraient saturer un petit VPS sans GPU, et macOS offre un shell Unix natif plus Homebrew sans surprises de réseau conteneurisé.
Un Mac mini M4 consomme environ 4 W au repos, reste très silencieux, et convient aux tunnels ou reverse proxies longue durée — avec une stabilité macOS nettement supérieure à une machine Windows bricolée et moins de friction opérationnelle que du matériel maison avec PCI pass-through.
Si vous voulez cette stabilité sans acheter tout de suite du métal, le Mac mini M4 cloud VPSSpark est un point de départ pragmatique — découvrez les formules et gardez OpenClaw, Ollama et une chaîne d’outils digne de Xcode sur un seul hôte cohérent.