2026 OpenClaw Linux-Cloud-VPS mit LAN- oder lokalem Ollama: Gateway-Upstream, TLS-Trennung, SSH-Tunnel und NO_PROXY-Matrix — reproduzierbare Schritte und gestufte FAQ zu 502 / Timeouts

OpenClaw auf einem kleinen Linux-Cloud-VPS zu betreiben, während Ollama auf einem Rechner zu Hause oder im Firmen-LAN bleibt, ist 2026 ein verbreitetes Layout: öffentliche Kanäle und Webhooks landen auf dem VPS, Gewichte und GPU bleiben dort, wo Strom und Policy passen. Die typischen Fehler sind fast immer Netzwerk — falsche Upstream-URL, TLS doppelt terminiert, ein firmenweites HTTP_PROXY, das Loopback-Verkehr abfängt, oder ein SSH-Tunnel, der nach Sleep leise weg ist. Dieser Artikel fasst ein reproduzierbares Verdrahtungsmuster und eine dreischichtige Triage zusammen, damit Sie nicht mehr raten, ob eine 502 von Nginx, vom Gateway oder von Ollama kommt, das gerade noch ein Modell in den VRAM lädt.

Topologie: wer welchen Hop besitzt

Stellen Sie sich eine gerade Linie vor: Browser oder Messenger-Kanal → TLS auf 443 → Reverse-Proxy (Caddy oder Nginx) → OpenClaw-Gateway auf einem Loopback-Port → HTTP-Client zu Ollama. Ollama kann auf demselben VPS auf 127.0.0.1:11434 lauschen, auf einer Docker-Bridge-IP oder auf einem per SSH von zu Hause durchgereichten Port. Schreiben Sie diese Liste auf, bevor Sie Konfigurationen ändern; sobald Sie localhost im Container mit localhost auf dem Host verwechseln, ohne Ports zu publizieren, entstehen „gestern ging es noch“-Bugs.

Gateway-Upstream zu Ollama

Richten Sie das Modell-Backend des Gateways auf genau eine kanonische Basis-URL — typisch http://127.0.0.1:11434, wenn Ollama mit auf dem Host liegt, oder http://127.0.0.1:18080, wenn Sie einen Tunnel auf einen festen lokalen Port legen. Vermeiden Sie eine zusätzliche HTTPS-Hop-Kette auf derselben Maschine, es sei denn, Sie mögen doppelte Verschlüsselung und Zertifikatsfehler. Nach jeder Änderung /api/tags mit curl unter demselben Benutzer testen, den systemd nutzt; wenn curl funktioniert, das Gateway aber nicht, liegt es an anderem User, anderem Netzwerk-Namespace oder einem veralteten Unit-Override. Für produktives TLS und Rollback um das Gateway halten wir eine längere Checkliste in 2026 OpenClaw Gateway in Produktion auf Linux: openclaw onboard, openclaw doctor und --fix, HTTPS mit Nginx oder Caddy, Upgrade und Rollback bereit.

TLS-Trennung: öffentlicher Rand vs. internes HTTP

TLS nur am Reverse-Proxy terminieren. Caddy oder Nginx spricht nach außen HTTPS und nach innen Klartext zu 127.0.0.1:18789 (Beispiel-Gateway-Bindung). Wenn der Proxy stattdessen auf einen https://-Upstream auf Loopback zeigt, müssen Sie für diesen inneren Hop eigene Zertifikate pflegen und im gleichen Rhythmus wie außen erneuern — meist unnötig. HTTP/1.1-Keep-Alive zu Ollama für Streaming aktivieren; manche Proxy-Vorlagen puffern Antworten und verhindern Streaming — prüfen Sie, ob die komplette Completion erst am Ende weitergegeben wird. Wenn Sie die exponierte Fläche reduzieren, vergleichen Sie SSH-only mit öffentlichem HTTPS anhand der Matrix in 2026 OpenClaw Linux-Cloud-VPS: Minimale Angriffsfläche — Firewall-Vorlage, Gateway-Loopback-Bindung und SSH-Tunnel für die Verwaltungsebene, Entscheidungsmatrix gegenüber HTTPS-Reverse-Proxy im öffentlichen Netz und gestufte FAQ.

Reproduzierbarer SSH-Tunnel (Heim-Ollama → VPS)

Von einem dauerhaft laufenden Heimrechner mit Ollama aus rückwärts zum VPS tunneln, damit die Cloud Ollama als Loopback sieht: ssh -N -o ServerAliveInterval=30 -o ExitOnForwardFailure=yes -R 127.0.0.1:18080:127.0.0.1:11434 user@vps. Auf dem VPS zeigt der Gateway-Upstream auf http://127.0.0.1:18080. GatewayPorts no beibehalten, Schlüssel nutzen und den Client auf der Heimseite unter systemd laufen lassen, damit Sleep den Tunnel nicht unbemerkt killt. Dokumentieren Sie, welche Seite Port 18080 besitzt, bevor Tickets aufgehen.

# Ollama über weitergeleiteten Port erreichbar
curl -sS http://127.0.0.1:18080/api/tags | head

# Gateway-Health hinter dem Proxy (Host ersetzen)
curl -sS https://gw.example.com/healthz

NO_PROXY und Umgebung (Matrix)

Viele VPS-Images exportieren HTTP_PROXY für Spiegel; Groß- und Kleinschreibung angleichen oder für die Gateway-Unit ganz entfernen. Nutzen Sie die Matrix, wenn Ollama strikt auf Loopback bleiben soll.

Gestufte Triage: 502 vs. Hängen vs. Reset

Schicht A — Edge: Nginx- oder Caddy-Fehlerprotokolle lesen; connect() failed (111: Connection refused) bei HTTPS bedeutet: auf dem Upstream-Port lauscht nichts. Schicht B — Gateway: ausgehende URL mit dem vergleichen, das dieselbe Unit per curl erreicht. Schicht C — Ollama: Logs auf Modell-Ladung; das erste Token nach Kaltstart kann Standard-read_timeout des Proxies sprengen. Wenn nur lange Prompts scheitern, zuerst Body-Limits am Edge prüfen, bevor Ollama beschuldigt wird.