OpenWebUI Nginx Reverse Proxy: TLS und WebSocket

TL;DR

Ein OpenWebUI Nginx Reverse Proxy terminiert TLS und reicht den Chat an den Container weiter. Die Herstellerdoku verlangt drei Dinge, sonst bricht Streaming oder Login: CORS_ALLOW_ORIGIN auf die öffentliche HTTPS-URL, WEBUI_URL auf dieselbe Adresse, und im Location-Block proxy_http_version 1.1 plus Upgrade/Connection. proxy_buffering muss aus, sonst zerlegt Nginx Server-Sent Events und Markdown erscheint zerstückelt. Gelesen in der Nginx-Referenz, der HTTPS-Übersicht und der Connection-Error-Seite am 2026-10-10. Das ist kein Ranking und kein Kaufguide.

UI-Proxy, nicht Ollama-Port

IT-Leiter suchen „openwebui nginx reverse proxy“, wenn der Chat über HTTPS erreichbar sein soll, die Stimmeingabe im Browser fehlt oder Antworten mit sichtbaren ## und ** ankommen. Die OpenWebUI-plus-Ollama-Compose hebt die Oberfläche; dieser Text behandelt nur die Schicht davor.

Ollama bleibt intern. Port, Firewall und Bind-Adresse stehen in Ollama Port 11434. Docker-Start der Engine: Ollama Docker. Den Linux-Dienst prüft Ollama Service.

Die HTTPS-Übersicht listet Nginx als Weg für „Self-hosted production with full control“, TLS manuell oder über Let's Encrypt. Caddy, HAProxy oder ein Cloud-Load-Balancer sind andere Wege, kein Vergleichssieger.

HTTPS verschlüsselt Chatverlauf, Zugangsdaten und Uploads. Dieselbe Seite: Voice Calls brauchen einen sicheren Kontext. Ohne HTTPS blockiert der Browser das Mikrofon, außer auf localhost.

Umgebungsvariablen vor dem ersten Login

Die Connection-Error-Doku, Abschnitt „Required Configuration for HTTPS & Reverse Proxies“. Setzen Sie die Werte an die öffentliche URL, nicht an http://127.0.0.1:3000, sobald Nutzer über den Proxy kommen.

WEBUI_URL=https://chat.example.com
CORS_ALLOW_ORIGIN="https://chat.example.com"
WEBUI_SESSION_COOKIE_SECURE=true
WEBUI_AUTH_COOKIE_SECURE=true
WEBUI_SESSION_COOKIE_SAME_SITE=lax
WEBUI_AUTH_COOKIE_SAME_SITE=lax

WEBUI_URL muss laut dieser Seite vor OAuth/SSO stehen. Nach dem ersten Start ändert sie sich nur über ENABLE_PERSISTENT_CONFIG=false, über Settings → Admin → System → General → WebUI URL, oder wenn sie vor dem ersten Launch gesetzt war. Die Nginx-Doku nennt dasselbe Feld in der Admin-Oberfläche „Webhook URL“ — dieselbe öffentliche Host-Adresse.

CORS_ALLOW_ORIGIN muss zur öffentlichen URL passen. Sonst scheitern WebSockets, auch wenn Nginx Proxy Manager „Websockets support“ angehakt hat. Mehrere Origins trennt die Doku mit Semikolon. Logs der Form „is not an accepted origin“ bedeuten: diese URL fehlt in der Liste.

Ohne HTTPS die Cookie-Flags SECURE nicht setzen. Die Doku sagt explizit: Disable if you do not use HTTPS. lax statt strict für OAuth-Callbacks.

WebSockets sind laut derselben Seite ab Open WebUI v0.5.0 Pflicht. ENABLE_WEBSOCKET_SUPPORT=true plus Redis nur, wenn Sie mehrere Instanzen betreiben. Der empfohlene Weg bleibt: Upgrade-Header im Proxy.

Rollen und API-Keys gehören nicht hierher, sondern nach OpenWebUI Teams.

Location-Block: HTTP/1.1, Upgrade, kein Buffering

Kritischer Block aus der Nginx-Referenz. HTTP/2 darf am Client an, der Weg zum Backend bleibt HTTP/1.1. WebSockets über RFC 8441 (WebSockets over H2) gelten in vielen Proxy-Umgebungen als unstabil.

location / {
    proxy_pass http://open-webui:8080;
    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-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;

    proxy_buffering off;
    proxy_cache off;
}

proxy_pass http://open-webui:8080 steht im Let's-Encrypt-Beispiel der Doku (Compose-Service open-webui, Container-Port 8080). Das Self-Signed-Docker-Beispiel zeigt host.docker.internal:3000. Das Windows-ohne-Docker-Beispiel zeigt localhost:8080. Das „Complete Optimized“-Beispiel zeigt 127.0.0.1:3000. Drei Dokumentationsvarianten, kein dritter Port erfunden.

proxy_buffering ist in Nginx standardmäßig an. Die Doku nennt das die häufigste Ursache für zerstückeltes Markdown: SSE-Chunks trennen **bold** in ** + bold + **. Symptome laut Referenz: sichtbare ##/**, fehlende Wörter, Streaming nur ohne Proxy sauber. Zusätzlich proxy_cache off.

Die HTTPS-Übersicht verlangt dieselben Upgrade-Header und „Proxy buffering off“. X-Forwarded-Proto muss $scheme sein, sonst erzeugt die App http-Links hinter HTTPS.

Timeouts und Body-Größe

Die HTTPS-Übersicht: Proxy-Read-Timeouts mindestens 300 Sekunden, weil LLM-Antworten Minuten dauern können.

Die Nginx-Referenz setzt in den Let's-Encrypt- und Optimized-Beispielen für Completions 1800 (in der Doku als 30 Minuten bezeichnet) auf proxy_read_timeout, proxy_send_timeout und proxy_connect_timeout. Auth-/API-Locations in demselben Let's-Encrypt- Block nutzen proxy_read_timeout 10m. Nginx Proxy Manager nennt als Default 60 Sekunden und dasselbe 1800 im Advanced-Tab.

WebSocket-Pfade im Optimized-Abschnitt:

location ~ ^/(ws/|socket\.io/) {
    proxy_pass http://openwebui;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
    gzip off;
    proxy_buffering off;
    proxy_cache off;
    proxy_connect_timeout 86400;
    proxy_send_timeout 86400;
    proxy_read_timeout 86400;
}

86400 steht in der Doku als 24-Stunden-Timeout für persistente Verbindungen. Das ist ein Konfigurationswert, kein SLA.

client_max_body_size 20M steht in den Let's-Encrypt- und Self-Signed-Location-Blöcken. Der Optimized-Abschnitt nennt im http-Block 100M für große Uploads. Nehmen Sie den Wert aus der von Ihnen kopierten Vorlage, erfinden Sie keinen dritten.

Auth-Pfade (/auth, /api, /oauth, /admin, /signin, /signup, /signout, /login, /logout, /sso) sollen laut Let's-Encrypt- Beispiel nicht gecacht werden (proxy_no_cache 1, Cache-Control: no-store). Statische Endungen dürfen cachen; die Doku setzt dort expires 7d.

ssl_protocols TLSv1.2 TLSv1.3 steht in Let's-Encrypt- und Self-Signed-Blöcken. Die Connection-Error-Checkliste verlangt dieselben Protokollversionen.

Let's Encrypt oder selbst signiert

Die Nginx-Referenz beschreibt drei Wege: selbst signiert (Docker), Let's Encrypt (Docker), Windows plus selbst signiert ohne Docker.

Let's Encrypt stellt keine Zertifikate für eine reine IP aus — ein Domainname mit A-Record ist Voraussetzung. Ablauf der Zertifikate: 90 Tage. Die Doku legt einen Cron auf 30 3 * * * mit certbot renew und einem Deploy-Hook, der den Nginx-Container neu startet.

Phase 1 der Let's-Encrypt-Anleitung: Nginx nur auf Port 80, location /.well-known/acme-challenge/ auf /var/www/certbot. Phase 2: 443 mit fullchain.pem und privkey.pem.

Selbst signiert: openssl req -x509 -nodes -days 365 -newkey rsa:2048. Browser warnen. Für interne Tests und Mikrofon im LAN reicht das laut Doku, für öffentliche Zugänge nicht.

Nginx Proxy Manager: Image jc21/nginx-proxy-manager:latest, Ports 80, 81 und 443. UI auf Port 81. Proxy-Host: Scheme HTTP, Websockets support an, Zertifikat, Force SSL. Zusätzlich im Advanced-Tab proxy_buffering off und proxy_cache off. Ohne diese zwei Zeilen gilt dasselbe SSE-Problem.

Prüfen

Connection-Error-Doku, „Testing Your Configuration“:

1. Zertifikat im Browser ohne Warnung (Let's Encrypt) oder bewusst akzeptiert (selbst signiert).
2. Entwicklertools → Network → Filter WS: Verbindung steht.
3. Konsole ohne CORS-Fehler.
4. Eine Chat-Antwort streamt, Markdown bleibt intakt.

Direkt gegen den Container ohne Proxy testen, wenn unklar ist, ob Nginx oder Open WebUI die Ursache ist.

Hardware-Kauf bleibt der KI-Server-Hardware-Guide. Dieser Text ändert keine GPU-Wahl.

Typische Brüche

CORS fehlt, Websockets support ist an. Die Doku nennt das den schwer zu findenden Fall. CORS_ALLOW_ORIGIN setzen, nicht nur die NPM-Checkbox.

Buffering an. Sichtbare ## und **, fehlende Wörter. Streaming ohne Proxy sauber, mit Proxy kaputt. proxy_buffering off.

HTTP/2 bis zum Backend. UI friert ein. proxy_http_version 1.1 im Location-Block.

WEBUI_URL nach dem ersten Start nur in der Compose-Datei geändert. Persistent Config überschreibt. Admin-Feld oder ENABLE_PERSISTENT_CONFIG=false.

Cookie SECURE ohne HTTPS. Login-Schleife. Flags nur bei TLS.

Ollama-Port 11434 im Proxy statt 8080/3000 der UI. Nutzer landen auf der Engine-API, nicht im Chat.

Zwei Timeouts. Default 60 Sekunden (NPM) bei langen Completions. Doku: mindestens 300 Sekunden, Beispiele 1800.

FAQ

Reicht Port-Mapping 3000:8080 ohne Nginx?

Für einen Test auf dem Host ja. Öffentlicher HTTPS-Zugang, Mikrofon außerhalb von localhost und sauberes Streaming über eine Domain brauchen den Reverse Proxy laut den gelesenen Seiten.

Muss ich Ollama ebenfalls durch Nginx schicken?

Nicht für denselben Hostnamen. Die UI spricht intern mit Ollama. Öffnen Sie 11434 nicht mit, nur weil der Chat über 443 läuft.

Warum Voice Calls ohne HTTPS tot sind

Die HTTPS-Übersicht: moderne Browser sperren das Mikrofon auf unsicheren Origins. Ausnahme localhost.

Kann ich HTTP/2 am Client behalten?

Ja. Die Nginx-Doku sagt: HTTP/2 am Server ist zulässig, der proxy_pass zum Backend bleibt HTTP/1.1 mit Upgrade.

Ändert Nginx die Modelle oder den VRAM-Bedarf?

Nein. Proxy und TLS liegen vor der UI. Modellwahl bleibt in Open WebUI bzw. Ollama.

Fazit

„OpenWebUI Nginx Reverse Proxy“ ist TLS plus korrekte Proxy-Header: WEBUI_URL, CORS_ALLOW_ORIGIN, HTTP/1.1-Upgrade, Buffering aus, Timeouts aus der Herstellerdoku. Ollama bleibt intern. Kein zweiter Hardware-Kaufguide und keine Anbieterliste.