Teams, die OpenClaw auf mehreren vpshalo-Regionen betreiben, brauchen einen stabilen HTTPS-Eingang ohne öffentliche Bind an 0.0.0.0. Ein Cloudflare Named Tunnel mit versionierter ingress-Datei fixiert den Pfad von Hostname zu 127.0.0.1; anschließend lassen sich synthetische JSON-Zeilen fensterweise mergen, damit Alarme nicht pro PoP zerfasern.

Dieses HowTo ergänzt den Loopback- und SSH-Reverse-Tunnel-Artikel sowie Tailscale MagicDNS für mehrere Regionen. Edge-Schichten und SSH-p95-Abnahme bleiben im Worker-Halo-Leitfaden; hier liegt der Fokus auf cloudflared, TUNNEL_TOKEN und reproduzierbarem Betrieb je PoP.

Typische Schmerzpunkte ohne festen ingress

  • 1 Flüchtige Quick-Tunnel-URLs: schwer in Runbooks und Zertifikatsüberwachung zu verankern, erschweren Eskalationen mit Resolver- und Browser-Caches.
  • 2 Doppelte Bindungen: OpenClaw lauscht versehentlich auf allen Schnittstellen; Zugriffskontrolle und Audit werden undurchsichtig.
  • 3 Zerstreute Telemetrie: gleiche Fehlerklasse in Tokio und Frankfurt erzeugt vier Tickets, wenn JSON-Felder nicht harmonisiert sind.
Modus Ingress-Definition Geheimnis / Auth Empfehlung vpshalo
Quick Tunnel (try) temporär, oft CLI-generiert wechselnde Hostnamen nur Smoke-Tests
Named Tunnel + config.yml explizite hostname-Zeilen TUNNEL_TOKEN pro Tunnel Produktion je Region
SSH Reverse (-R) Port auf Bastion SSH-Keys, Rotation siehe Parallel-Artikel

Reproduzierbare Schritte (je Region einmal)

  • 1 Isolation: OPENCLAW_HOME=/var/lib/openclaw/<region> setzen, HTTP nur 127.0.0.1:18080 (Beispielport). Verifikation mit curl -fsS http://127.0.0.1:18080/healthz.
  • 2 Tunnel anlegen: cloudflared tunnel login, dann tunnel create openclaw-<region> und DNS-CNAME gemäß Anzeige delegieren.
  • 3 ingress fixieren: in config.yml hostname: oc.<region>.example.com auf http://127.0.0.1:18080 mappen; letzte Regel http_status:404 als Fangnetz.
  • 4 Token und Dienst: cloudflared tunnel token ausgeben, per EnvironmentFile einbinden, Unit mit ExecStart=cloudflared tunnel run und Restart=on-failure.
  • 5 Öffentlicher Test: curl -fsS https://oc.<region>.example.com/healthz. Fehler zuerst in journalctl -u cloudflared, dann Loopback erneut prüfen.
  • 6 Merge vorbereiten: strukturierte Einzeiler mit region, lane, rtt_ms, error_class schreiben; Aggregator wertet Fünf-Minuten-Fenster aus und dedupliziert nach Host.
Veröffentlicht keine Admin-Pfade ohne zusätzliche Absicherung (z. B. Cloudflare Access). Ein Tunnel pro Region hält Blast-Radius und Token-Rotation überschaubar.

Merge synthetischer Ausgaben

Legt ein gemeinsames Schema für Fehlerklassen und RTT fest. Pro Fenster maximiert ihr die Schwere, nicht die Anzahl Rohereignisse—so bleibt ein einzelner Alarm pro Vorfall lesbar, wenn cloudflared kurz reconnectet oder ein Lane-Canary rot wird. Speichert die Fensterbreite (300 s ist ein pragmatischer Startwert) im gleichen Repo wie die ingress-Datei, damit Review und Rollback dieselbe Quelle haben.

Nach dem ersten grünen Durchlauf versioniert ihr config.yml und die systemd-Unit mit demselben Tag wie die OpenClaw-Konfiguration. Ingress-Änderungen laufen über einen kurzen Canary-Hostnamen auf dieselbe Loopback-Instanz, bevor ihr alte Namen entfernt—so fallen abweichende Header oder Payload-Felder in Staging auf, statt in Produktion. Agenten auf dem vpshalo-Knoten sollten cloudflared-Prozesse, offene Dateideskriptoren und RESTART-Zähler der Unit mitschneiden; wiederholte Restarts ohne erfolgreichen Handshake deuten meist auf Token- oder DNS-Brüche hin, nicht auf OpenClaw selbst.

Parameter Starterwert Stabilitätsnotiz
cloudflared-Version Minor fix pin je Region Gleiche Binärversion auf allen PoPs verhindert divergente ingress-Syntax
systemd RestartSec 5–10 s Exponentielles Backoff optional; verhindert Log-Stürme bei DNS-Aussetzern
Merge-Fenster 300 s Kürzer für interaktive Demos, länger für Batch-Builds mit seltener Telemetrie
healthz Client-Timeout 2 s Getrennt vom Upstream-Timeout des Tunneleingangs dokumentieren
Öffentliches DNS-TTL 300–600 s Kurz genug für geplante Umzüge, lang genug gegen Resolver-Flap
Logaufbewahrung lokal 14 Tage Abgleich mit zentralem SIEM; keine Klartext-Tokens in Logs
Token-Rotation SLA ≤ 15 Min. Alle Units einer Region im selben Wartungsfenster aktualisieren

Für gemischte Teams empfiehlt sich ein kurzes internes Abnahmeblatt: Loopback-Check, öffentlicher healthz-Check, Merge-Sample mit zwei Regionen, abschließend Kaufreferenz auf den gebuchten PoP. So bleibt die Betriebsrealität auf vpshalo mit den öffentlichen Seiten konsistent und Auditoren sehen eine durchgängige Kette von Konfigurationsdatei bis Bestellnachweis.

FAQ: Zertifikate, Ports, Token

Zertifikate: Endet TLS bei Cloudflare und spricht cloudflared per HTTP mit dem Loopback, benötigt OpenClaw dort kein öffentliches Serverzertifikat. Sichert dennoch den lokalen Zertifikatscache von cloudflared in eure Backups ein, damit Wiederanläufe nach Restore nicht hängen bleiben.

Ports: Ein freier TCP-Port pro Region dokumentieren, identisch in Unit-Datei und ingress. Prüft mit ss -lntp, dass nur 127.0.0.1 gebunden ist; Konflikte mit CI- oder Debug-Diensten vermeidet ihr über reservierte Portbereiche im internen Handbuch.

TUNNEL_TOKEN: Nie im Git ablegen; Rotation nach Leck oder Teamwechsel mit gleichzeitigem Rollout auf allen Knoten einer Region. Secrets aus Vault oder dem Hoster-eigenen Secret-Store injizieren—Details zu Konto- und Netzfragen bündelt das Hilfe-Center mit den öffentlichen Kauf- und Betriebsseiten.

Hinweis: CLI-Flags und Pfade können sich zwischen cloudflared-Versionen leicht unterscheiden; vor Produktionsänderungen die Release Notes lesen.

Kauf- und Kapazitätsfokus: Wählt den vpshalo-PoP, in dem eure OpenClaw-Instanzen und eure Remote-Mac-Builds dieselbe RTT-Schicht teilen. Nach dem Rollout einmalig öffentliche healthz- und SSH-Timings wiederholen und im Status-Dokument verankern—so bleibt gebuchte Kapazität an messbare Netz-Evidenz gebunden statt nur als weiterer Hostname zu existieren.

Öffentliche Seiten — nächster Schritt

Tunnel-Betrieb und Mac-Kapazität abstimmen

Auf der Titelseite den Leistungsumfang prüfen, unter Preise Region und Ressourcen vergleichen, im Hilfe-Center Anschluss und Supportpfade lesen und den Remote Mac über Kaufen buchen—parallel zu euren Tunnel-Knoten. Den Technologie-Blog nutzt ihr für Worker-, GeoDNS- und OpenClaw-Vertiefungen.

Jetzt Remote Mac mieten Tarife ansehen Hilfe-Center Weitere Blog-Artikel