OpenClaw 2026 et domaine de production :
proxy inverse Caddy ou Nginx + TLS et checklist Gateway localhost (Docker VPS)

Terminaison TLS · WebSocket · allowedOrigins · Checklist mise en ligne Docker

2026 OpenClaw proxy inverse TLS et surface Gateway

Les ingénieurs qui font tourner OpenClaw sur un VPS en Docker et veulent un vrai nom d'hôte HTTPS restent souvent bloqués sur où le Gateway écoute, qui termine le TLS et pourquoi la Control UI signale du cross-origin ou un repli non sûr. L'article propose une table de décision boucle locale plus proxy de bord contre ports conteneur publics, des snippets minimaux Caddy et Nginx, des en-têtes WebSocket et X-Forwarded et un ordre d'acceptation pour allowedOrigins. OOM et premier WASM : long article Docker VPS. Installation : guide v2026.4 ; durcissement : multicanal ; rollback : pin.

01

Six points pénibles : curl localhost ne garantit pas le domaine public

En Docker, la prod inclut aussi pare-feu hôte, publish sur 127.0.0.1 seulement, chaîne complète et callbacks HTTPS. Liste pour triage ; détails dans la doc versionnée.

  1. 01

    Habitude 0.0.0.0 : Gateway public sans WAF ni audit élargit la surface.

  2. 02

    WebSocket partiel : pas de Upgrade / Connection, panneau 502 ou handshake KO.

  3. 03

    Dérive host/origin : navigateur en A, config en IP ou alias interne, garde cross-origin.

  4. 04

    Certificat avant DNS : émission précoce ou mélange self-signed/public.

  5. 05

    Logs et disque : sans rotation, inodes saturés sur petit VPS.

  6. 06

    Fenêtre de mise à jour : rolling sans image épinglée sans staging/rollback.

Note : OOM, Exit 137, WASM ou allowedOrigins : voir article triage.

02

Table d'exposition : boucle locale et TLS au proxy par défaut

Pour sortir OpenClaw du labo vers un hôte réel : HTTPS, canaux et observabilité sur une même narration d'acceptation.

Axe127.0.0.1 + proxy TLSPort conteneur public
Surface minimaleInternet touche 443 seulement, upstream en boucleACL réseau et revue de ports continues
Certificatsune chaîne Caddy / Nginx / ACMEchaque app ou sidecar dérive
WebSocketmodules matures gèrent upgrade et timeoutsen-têtes perdus ; debug direct masque le trou
Observabilitélogs edge et upstream joignables via request_idvous reconstruisez agrégation et alertes

Principe prod : cocher ensemble « panneau charge » et « les canaux rappellent le https annoncé » sur la même liste.

Rappels durs sur les ports

  • Si le port Gateway documenté (souvent 18789) diverge, parcourir config et compose ; ne modifiez pas seulement le proxy.
  • allowedOrigins doit couvrir l'https réel ; après edits redémarrer froid selon article triage.
  • Instances multiples : callbacks et TTL DNS sur le ticket de changement.
03

Runbook en six étapes : du DNS aux snippets

Compose doit déjà exposer le Gateway loopback uniquement ; sinon finir wizard et baseline compose.

  1. 01

    Geler le hostname : A/AAAA vers ce VPS, TTL et fenêtre de maintenance.

  2. 02

    Bind Gateway : ss -lntp, vérifier 127.0.0.1 et le bon port.

  3. 03

    Choisir le proxy : minimal = Caddy HTTPS auto ; Nginx existant via stream/location.

  4. 04

    Snippet minimal : blocs ci-dessous, upstream = port doc + hostname réel.

  5. 05

    Callbacks : IM/webhook utilisent le même hôte public et préfixe.

  6. 06

    Golden path : du https navigateur à un heartbeat ou doctor bénin dans le playbook interne.

Caddyfile
openclaw.example.com {
    encode gzip
    reverse_proxy 127.0.0.1:18789
}
nginx
server {
    listen 443 ssl http2;
    server_name openclaw.example.com;
    ssl_certificate     /etc/letsencrypt/live/openclaw.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/openclaw.example.com/privkey.pem;
    location / {
        proxy_pass http://127.0.0.1:18789;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_read_timeout 600s;
    }
}
04

Triage : symptôme → couche → premier geste

Chaque ligne doit pointer vers un log ou une commande concrète.

SymptômeCoucheGeste
HTTPS échoue, HTTP brut upstream okchaîne ou SNIvalider la chaîne et server_name
Statique OK, canal live coupetimeout WebSocketaugmenter read timeout, vérifier Upgrade
Cross-origin consoleallowedOriginsréécrire les origines, redémarrer
curl public 502, local 200upstream proxy ou bindparcourir compose/publish

Attention : sans hardening multicanal, pas de dashboard en 0.0.0.0 pour démo.

05

Repères quantitatifs pour tickets

Plages typiques VPS unique, pas de SLA fournisseur.

  • Timeout lecture proxy : garder ≥ 600 s (proxy_read_timeout ou équivalent Caddy).
  • Renouvellement : alerte ACME ≥ 14 jours avant expiration.
  • Logs : centaines de MB/semaine fréquentes ; mesurer df et inodes la première semaine.
RôleProfilReco
Persofaible traficun Caddy, un compose, fenêtre manuelle
Petite équipecanaux journéeimage épinglée, rollback échelonné
Mac / CIjobs longs + signatureGateway sur VPS, builds pool Mac

ISP domestique ou petit cloud instable comme seule entrée empile IP dynamique et sommeils surprises.

Pour une porte https durable et séparer agents longue durée et pool iOS CI, location Mac mini cloud VpsMesh + VPS permanent est souvent plus stable : calcul sur nœuds contractuels, Gateway selon ce runbook.

FAQ

FAQ

TLS et débit au proxy familier, sessions au Gateway. Exposition publique : points de la checklist durcie. Capacité : tarifs et commander.

Vérifier l'origine complète (port inclus) dans allowedOrigins. Cas compose : article Docker VPS ; self-service : centre d'aide.

Souvent il suffit de vérifier port et health. Si chemins ou WebSocket bougent : release notes et double instance selon pin et rollback.