2026 OpenClaw sur nœuds vpshalo multirégion
Cloudflare Tunnel, ingress figé & fusion des sorties

Les équipes adoptent les Named Tunnels lorsqu’elles font déjà confiance à Cloudflare pour le DNS et souhaitent le même flux de revue pour l’entrée HTTP que pour les Workers. Le piège opérationnel est de traiter le fichier config.yml (ingress) comme du code applicatif : règles ordonnées, noms d’hôte explicites, et une règle finale « attrape-tout » qui renvoie 404 afin que les scans aléatoires n’atteignent jamais OpenClaw. Lorsqu’il faut en plus du steering au bord au-delà de ce que l’ingress seul permet, lisez en parallèle le guide Worker façon « Halo », routage et SSH p95 — cet article reste centré sur cloudflared, la liaison loopback et la manière de fusionner les sondes émises par plusieurs PoP sans doublons d’alerte.

Pourquoi figer l’ingress

Les URL « Quick Tunnel » conviennent aux démos ; en production sur vpshalo, viser un Named Tunnel plus un fichier d’ingress référencé dans le contrôle de version. Ce fichier est le contrat entre Cloudflare et votre origine : quel nom public pointe vers quel http://127.0.0.1:PORT, quels chemins sont autorisés, et ce qui se passe lorsqu’aucune règle ne correspond. Lorsque chaque région ne diffère que par le nom d’hôte et le port, votre worker ou script de fusion peut supposer la même sémantique partout. Rangez le fichier à côté du modèle d’unité systemd : un revert Git suffit pour un retour arrière.

Gardez l’écoute HTTP d’OpenClaw hors des interfaces routables. Si quelqu’un lie « juste cinq minutes » sur 0.0.0.0, le modèle de menace du tunnel est contourné. Les seuls clients HTTP locaux devraient être cloudflared et vos sondes sur localhost ; tout accès navigateur doit terminer TLS chez Cloudflare, puis traverser le tunnel.

Étapes reproductibles (une fois par région vpshalo)

Remplacez les étiquettes d’inventaire ; ports et chemins sont des exemples à caler sur votre build OpenClaw.

• Étape 1 — Isoler OpenClaw sur loopback. Exportez OPENCLAW_HOME=/var/lib/openclaw/<region> (ou le chemin macOS de votre image). Démarrez OpenClaw avec des drapeaux de liaison explicites pour que la passerelle n’écoute que sur 127.0.0.1:18080. Depuis la même machine, exécutez curl -fsS --max-time 2 http://127.0.0.1:18080/healthz jusqu’à obtenir un succès stable.
• Étape 2 — Créer le Named Tunnel et le DNS. Installez cloudflared, lancez cloudflared tunnel create openclaw-<region>, puis créez le CNAME que Cloudflare attend pour <region>.gw.example.com. Conservez l’UUID du tunnel et le nom lisible dans votre CMDB : les rotations et les audits en dépendent.
• Étape 3 — Figer l’ingress. Rédigez config.yml avec un bloc tunnel pointant vers le JSON d’identifiants, puis une liste ingress qui mappe https://<region>.gw.example.com/* vers http://127.0.0.1:18080. Terminez toujours par - service: http_status:404 pour que le trafic non couvert ne retombe pas par erreur sur la première règle après une édition malencontreuse.
• Étape 4 — Exécuter avec TUNNEL_TOKEN sous systemd. Dans Zero Trust, copiez le jeton du tunnel. Écrivez /etc/default/cloudflared-openclaw (droits 0600) contenant TUNNEL_TOKEN=… et pointez l’unité vers cloudflared tunnel run --config /etc/cloudflared/openclaw-<region>.yml. Activez Restart=on-failure avec un backoff raisonnable pour ne pas marteler le plan de contrôle.
• Étape 5 — Valider bordure → origine. Depuis un exécuteur CI hors VLAN bureau, appelez l’URL publique en HTTPS. Comparez avec le healthz loopback : si le bord est vert mais pas le local, le défaut est sur la boîte ; si les deux échouent ensemble, suspectez d’abord le processus applicatif, pas le certificat du tunnel.

# Sur l’origine : le loopback doit répondre avant que cloudflared compte
curl -fsS --max-time 2 http://127.0.0.1:18080/healthz

# Après propagation DNS : contrôle bord (pas de certificat client spécial)
curl -fsS --max-time 5 https://usw.gw.example.com/healthz

Fusionner les sorties de sondes entre régions

Donnez à chaque sonde la même forme JSON pour que la fusion reste ennuyeuse : region, lane (loopback, tunnel_origin, edge_https), rtt_ms, http_status et error_class. Émettez une ligne par contrôle vers stdout ou vers votre bus de journaux. Un worker de quelques dizaines de lignes (ou une requête planifiée) classe les événements dans des fenêtres glissantes de cinq minutes indexées par région.

Politique de pagination illustrée : une page régionale unique lorsque toutes les voies échouent dans le même compartiment ; escalade « multirégion » seulement si au moins deux régions perdent la voie edge_https dans la même fenêtre. Cela réduit les alertes redondantes lorsque Cloudflare est sain mais votre FAI bureau oscille : loopback et tunnel_origin peuvent rester verts pendant qu’edge_https clignote — la FAQ ci-dessous précise quand ignorer ce motif.

• Voie A — loopback : signal peu coûteux, cron chaque minute sur l’hôte modèle.
• Voie B — tunnel_origin : curl via 127.0.0.1 vers le même port que cloudflared, prouvant le câblage processus à processus.
• Voie C — edge_https : fréquence basse (toutes les cinq minutes) depuis un point extérieur pour ne pas confondre quotas et panne.

FAQ : certificat du tunnel, ports, jetons

Faut-il un certificat TLS sur l’hôte vpshalo pour OpenClaw derrière Cloudflare Tunnel ? En général non. Le TLS vu par l’utilisateur se termine chez Cloudflare ; cloudflared peut parler HTTP clair vers 127.0.0.1. Vous n’ajoutez une pile TLS en loopback que si la conformité impose du chiffrement jusqu’à l’origine — alors utilisez un certificat court depuis votre coffre, pas un wildcard public recopié dans Git.

Comment choisir et vérifier le port local ? Retenez un port élevé documenté par région (par exemple 18080), gardez la même valeur dans les drapeaux OpenClaw et dans l’ingress, et contrôlez avec ss -lntp qu’aucun autre service ne lie 0.0.0.0 sur ce port. Si vous changez de port, modifiez les deux fichiers dans le même commit pour éviter que cloudflared ne pointe vers un amont mort.

Comment traiter TUNNEL_TOKEN ? Comme une clé d’API cloud : jamais dans Git ni dans les tickets, chargement depuis un EnvironmentFile ou un gestionnaire de secrets, rotation immédiate en cas de fuite — régénérez le jeton et redémarrez tous les nœuds de la région ensemble pour éviter l’état scindé où la moitié de la flotte garde l’ancien secret.

Qu’est-ce qui casse en premier pendant un incident ? Le plus souvent le DNS ou un ingress obsolète dans Git, pas OpenClaw lui-même. Entraînez l’astreinte à comparer le config.yml déployé au dépôt avant de redémarrer le modèle.

Alignement achat : lorsque vous commandez de la capacité vpshalo, choisissez le PoP qui correspond déjà au RTT de votre tunnel et au placement du registre d’artefacts, afin que cloudflared, les builders et les gros binaires partagent la même enveloppe économique. Après bascule, relancez les sondes edge_https et consignez les nouvelles lignes de base dans le même document que votre fichier d’ingress — la capacité reste liée à des preuves, pas à un nom d’hôte oublié.