TLS-Terminierung · WebSocket · allowedOrigins · Docker Go-Live-Checkliste
Ingenieure, die OpenClaw bereits per Docker auf einem VPS betreiben und einen echten Hostnamen mit HTTPS anbinden wollen, bleiben oft bei der Frage hängen, wo das Gateway lauscht, wer TLS beendet und warum die Control UI im Browser Cross-Origin oder unsicheren Fallback meldet. Der Artikel nutzt eine Entscheidungstabelle für Loopback plus Edge-Proxy versus öffentlich gebundene Container-Ports, liefert minimale Caddy- und Nginx-Reverse-Proxy-Snippets, WebSocket- und X-Forwarded-Header sowie eine Abnahmereihenfolge für allowedOrigins. OOM und erste WASM-Läufe bleiben im langen Docker-VPS-Troubleshooting. Installationsüberblick: v2026.4-Installationsleitfaden; Produktionsexposition: Multichannel-Härtung; Rollback: Pin und Rollback.
Echter Docker-Betrieb umfasst auch Host-Firewall, Publish nur auf 127.0.0.1, vollständige Zertifikatskette und Kanal-Callbacks unter HTTPS. Die Liste dient der Erstlage; Details stehen in den Docs Ihrer Version.
0.0.0.0-Gewohnheit: Gateway ohne WAF, Rate-Limits und Audit auf öffentlicher Schnittstelle vergrößert die Angriffsfläche massiv.
WebSocket halbiert: Proxy leitet Upgrade / Connection nicht, Panel zeigt 502 oder Handshake bricht.
Host- und Origin-Drift: Browser nutzt Hostname A, Config bleibt bei IP oder internem Alias, Control UI und API blocken Cross-Origin.
Zertifikat vor DNS: Ausstellung vor DNS-Propagierung oder Mix aus self-signed und Public Chain erzeugt inkonsistente Clients.
Platte und Logs: Proxy- und Container-Logs ohne Rotation füllen Inodes auf kleinen VPS unter Last.
Upgrade-Fenster: Rolling ohne gepinnte Images splittet Gateway-Verhalten ohne Staging- und Rollback-Reihenfolge.
Hinweis: Blockiert OOM, Exit 137, erste WASM-Wartezeit oder allowedOrigins-Pairing, starten Sie beim Triage-Artikel; Speicherprofile wiederholen wir hier nicht.
Die Matrix richtet sich an Teams, die OpenClaw vom Labor auf einen Hostnamen heben: HTTPS, Kanäle und Observability sollen eine gemeinsame Abnahme erhalten.
| Dimension | 127.0.0.1 Gateway + Proxy-TLS | Containerport öffentlich gebunden |
|---|---|---|
| Minimale Fläche | Internet berührt nur 443, Upstream bleibt auf Loopback | eigene ACLs und fortlaufende Portaudits nötig |
| Zertifikate | eine Caddy/Nginx/ACME-Kette | Apps oder Sidecars pflegen jeweils Zertifikate |
| WebSocket | Proxy-Module handhaben Upgrade und Timeouts | Header gehen verloren; direktes Debuggen tarnt Lücken |
| Observability | Edge- und Upstream-Logs über request_id verknüpfbar | Aggregation selbst bauen |
Produktions-Grundsatz: Panel lädt und Kanäle erreichen denselben veröffentlichten https-Hostnamen – auf einer Liste abhaken.
18789) von Overrides ab, durchsuchen Sie Config und Compose vollständig; nur den Proxy zu ändern reicht nicht.allowedOrigins muss die reale Browser-https-Origin enthalten; nach Änderungen kalt starten wie im Triage-Artikel.Compose soll das Gateway bereits nur auf Loopback bringen; sonst zuerst Wizard- und Compose-Baseline schließen.
Hostname einfrieren: A/AAAA vor Zertifikatsausstellung prüfen, TTL und Wartungsfenster dokumentieren.
Gateway-Bind: mit ss -lntp verifizieren, dass nur 127.0.0.1 und der richtige Port lauschen.
Proxy wählen: Minimal: Caddy automatisches HTTPS; Nginx-Bestand mit stream/location anbinden.
Snippet legen: untenstehende Blöcke, Upstream auf Doc-Port und realen Hostnamen setzen.
Callbacks: IM/Webhook-URLs nutzen denselben öffentlichen Host und Pfadpräfix.
Golden Path: vom Browser-https bis harmlosem Heartbeat oder doctor im Playbook für Schichtwechsel.
openclaw.example.com {
encode gzip
reverse_proxy 127.0.0.1:18789
}
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;
}
}
Jede Zeile soll auf Logfeld oder Kommando zeigen, nicht auf Bauchgefühl.
| Symptom | Schicht | Erster Schritt |
|---|---|---|
| HTTPS scheitert, Roh-HTTP zum Upstream ok | Kette oder SNI | Kette prüfen, server_name zu CN/SAN |
| Statik lädt, Live-Kanal bricht | WebSocket-Timeout | read timeout erhöhen, Upgrade prüfen |
| Console: Cross-Origin | allowedOrigins ohne https | Liste neu schreiben, Prozesse neu starten |
| Öffentlich 502, lokal 200 | Proxy-Upstream falsch oder kein 127.0.0.1 | Compose/Publish hops ablaufen |
Achtung: Ohne vollständige Multichannel-Härtung kein Dashboard/Debug auf 0.0.0.0 für Demos.
Bandbreiten für Einzel-VPS, kein Hersteller-SLA.
proxy_read_timeout oder Caddy-Äquivalent.df und Inodes messen.| Rolle | Profil | Hinweis |
|---|---|---|
| Persönlich | wenig Traffic | ein Caddy, ein Compose, manuelles Fenster |
| Kleines Team | viele Kanäle tagsüber | gepinnte Images, gestaffeltes Rollback |
| Mac/CI | lange Jobs + Signing | Gateway VPS, Builds in Mac-Pool |
Nur Consumer-ISP oder instabile VM als Eingang stackt dynamische IPs und Überraschungs-Sleep.
Für eine stabile https-Front und Trennung langlebiger Agenten vom iOS-CI sind VpsMesh Cloud-Mac-Mini-Miete plus dauerhafte VPS oft die ruhigere Variante: Rechen- und Signaturlast auf Vertragsknoten, Gateway weiterhin nach diesem Runbook.
TLS, Raten und Audit bleiben am vertrauten Reverse Proxy, das Gateway kümmert sich um Sessions. Öffentliche Bindung erfordert die Punkte der Härtungs-Checkliste. Zusatzkapazität über Mietpreise und Bestellen.
Vollständige Browser-Origin inkl. Port in allowedOrigins prüfen; Mixed Content und IP/Hostname-Mix erzeugen Fehlalarme. Komplexe Fälle im Docker-VPS-Artikel; Self-Service im Hilfezentrum.
Meist genügt die Prüfung von Port und Health. Bei Pfad- oder WebSocket-Änderungen Release Notes lesen und doppelt testen laut Pin- und Rollback-Artikel.