Von MV2 von Munim, Inc. Geprüft am 12. Oktober 2026 anhand der Dokumentation von Open WebUI und n8n und des Quellcodes von Ollama. Diese Seite wurde mit KI aus dem englischen Original übersetzt; bei Abweichungen gilt das Original.
Typische Fehler: Open WebUI zeigt „Ollama: Network Problem“ oder „Server Connection Error“, oder in seinen Logs steht Connect call failed ('127.0.0.1', 11434). Der Test der Ollama-Zugangsdaten in n8n scheitert mit ECONNREFUSED 127.0.0.1:11434 oder ECONNREFUSED ::1:11434. Dify, Flowise und AnythingLLM melden ähnliche „connection refused“-Fehler.
Die Ursache: In einem Container bedeuten localhost und 127.0.0.1 den Container selbst, nicht Ihren Rechner. Ollama lauscht auf dem Host standardmäßig auf 127.0.0.1:11434. Ein Container, der http://localhost:11434 nutzt, klopft also an der falschen Tür.
Die schnelle Lösung, die viele Anleitungen nennen, ist OLLAMA_HOST=0.0.0.0. Das funktioniert, öffnet Ollama, das keinen Login hat, aber auch für jedes Gerät in Ihrem Netz. Probieren Sie zuerst die Lösungen unten.
Prüfen Sie auf dem Host, ob Ollama läuft: curl http://127.0.0.1:11434/api/version. Testen Sie dann die Adresse, die Ihre App nutzt, aus einem Wegwerf-Container heraus:
docker run --rm --add-host=host.docker.internal:host-gateway curlimages/curl -s http://host.docker.internal:11434/api/version
Eine Antwort wie {"version":"0.x.y"} bedeutet, dass diese URL aus Containern funktioniert. „Connection refused“ oder ein Timeout bedeutet, dass sie es nicht tut; lesen Sie dann bei Ihrem Setup weiter. Das Image von Open WebUI enthält curl, Sie können also auch docker exec open-webui curl -s http://host.docker.internal:11434/api/version ausführen.
| Ihr Setup | Basis-URL in der App | Hinweise |
|---|---|---|
| Docker Desktop (Mac oder Windows), Ollama-App auf dem Host | http://host.docker.internal:11434 | Funktioniert sofort; Ollama kann auf 127.0.0.1 bleiben. Lösung 1. |
| Linux, Ollama auf dem Host installiert, App in Docker | http://host.docker.internal:11434 plus --add-host | Ollama muss zusätzlich dort lauschen, wo Container es erreichen. Lösung 2 oder 3. |
| Ollama und die App in derselben Compose-Datei | http://ollama:11434 (der Dienstname) | Die beste Variante; Ollama braucht keinen veröffentlichten Port. Lösung 4. |
| Ollama in Docker, App auf dem Host installiert (zum Beispiel n8n über npm) | http://127.0.0.1:11434 | Veröffentlichen Sie mit -p 127.0.0.1:11434:11434. Nutzen Sie 127.0.0.1 statt localhost, um den ::1-Fehler zu vermeiden. |
Docker Desktop stellt jedem Container host.docker.internal bereit und leitet es an Ihren Rechner weiter. Setzen Sie die Ollama-URL der App also auf http://host.docker.internal:11434. Bei Open WebUI ist das die Umgebungsvariable OLLAMA_BASE_URL (oder „Admin Settings“ → „Connections“). In n8n bearbeiten Sie die „Base URL“ der Ollama-Zugangsdaten. OLLAMA_HOST muss bei Ollama nicht geändert werden.
docker run -d -p 127.0.0.1:3000:8080 --add-host=host.docker.internal:host-gateway \ -e OLLAMA_BASE_URL=http://host.docker.internal:11434 \ -v open-webui:/app/backend/data --name open-webui --restart always \ ghcr.io/open-webui/open-webui:main
127.0.0.1:3000 beschränkt Open WebUI auf diesen Rechner. Nutzen Sie -p 3000:8080 nur, wenn andere Geräte es öffnen sollen, und schalten Sie dann die offene Registrierung ab. Um es vom Handy aus zu erreichen, ohne es fürs Netz zu öffnen, siehe Open WebUI über Tailscale Serve.
Unter Linux setzt --network=host den Container ins Netz des Hosts. Dann ist 127.0.0.1:11434 wirklich das Ollama des Hosts, und Ollama kann an localhost gebunden bleiben. Die Dokumentation von Open WebUI nennt diese Lösung; beachten Sie, dass der Port dann 8080 ist:
docker run -d --network=host \ -e OLLAMA_BASE_URL=http://127.0.0.1:11434 \ -v open-webui:/app/backend/data --name open-webui --restart always \ ghcr.io/open-webui/open-webui:main
Öffnen Sie http://localhost:8080. Mit Host-Netzwerk lauscht Open WebUI wie ein normales Programm auf Port 8080, und hier greift die Firewall des Hosts (ufw, firewalld). Erlauben Sie 8080 nur von dort, wo Sie es brauchen.
Unter Linux zeigt --add-host=host.docker.internal:host-gateway (oder extra_hosts: ["host.docker.internal:host-gateway"] in Compose) diesen Namen auf die Adresse der Docker-Bridge, meist 172.17.0.1. Ein Ollama auf 127.0.0.1 lauscht dort nicht. Es muss also breiter lauschen, und eine Firewall muss alle außer den Containern draußen halten:
sudo systemctl edit ollama.service, dann hinzufügen:
[Service] Environment="OLLAMA_HOST=0.0.0.0:11434"danach
sudo systemctl daemon-reload && sudo systemctl restart ollama.sudo ufw allow from 172.16.0.0/12 to any port 11434 proto tcp sudo ufw deny 11434/tcpDie Reihenfolge zählt: Die Allow-Regel muss zuerst kommen (
sudo ufw status numbered zeigt die Reihenfolge). Ist ufw mit seinem Standard „deny incoming“ aktiv, lässt überhaupt erst die Allow-Regel die Container herein. Ein blockierter Container sieht meist einen Timeout statt „refused“.curl http://<this machine's LAN IP>:11434/api/version (mit der LAN-IP dieses Rechners) jetzt scheitern, während der Test mit dem Wegwerf-Container oben gelingt.Anders als mit docker -p veröffentlichte Ports, an denen ufw vorbeigeht, ist ein auf dem Host installiertes Ollama ein normales Programm, und diese ufw-Regeln gelten dafür.
Container im selben Compose-Netz erreichen sich über den Dienstnamen. Ollama braucht dann keinen veröffentlichten Port, und nichts außerhalb von Docker kann es erreichen:
services:
ollama:
image: ollama/ollama
volumes: [ "ollama:/root/.ollama" ]
# no "ports:" - only containers on this network can reach it
open-webui:
image: ghcr.io/open-webui/open-webui:main
environment:
- OLLAMA_BASE_URL=http://ollama:11434
ports: [ "127.0.0.1:3000:8080" ]
volumes: [ "open-webui:/app/backend/data" ]
volumes:
ollama: {}
open-webui: {}
(Der Kommentar in der Datei bedeutet: kein „ports:“, nur Container in diesem Netz erreichen Ollama.) n8n, Dify, Flowise oder AnythingLLM in derselben Datei nutzen ebenfalls http://ollama:11434. Für eine GPU ergänzen Sie beim Dienst ollama die Geräte-Reservierung aus der Docker-Dokumentation von Ollama. Läuft die App in einem anderen Compose-Projekt, hängen Sie beide an ein gemeinsames externes Netz.
ECONNREFUSED ::1:11434: localhost wurde zu IPv6 aufgelöst, Ollama lauscht aber auf IPv4. Die Dokumentation von n8n empfiehlt 127.0.0.1 statt localhost.host.containers.internal.OLLAMA_ORIGINS blockiert sie; siehe den Browser-Check (Englisch). Open WebUI, n8n und Dify rufen Ollama von ihrem Server aus auf und brauchen OLLAMA_ORIGINS nicht. (2) Ein Reverse-Proxy oder Tunnel reicht seinen eigenen Hostnamen an ein Ollama weiter, das auf 127.0.0.1 lauscht. In diesem Modus akzeptiert Ollama nur Host-Namen nach Art von localhost; deshalb funktioniert host.docker.internal (es endet auf .internal). Lassen Sie den Proxy Host: localhost:11434 senden, wie es die Beispiele der Ollama-FAQ tun. Tailscale Serve läuft in dieselbe Prüfung; siehe warum tailscale serve 403 liefert.Sobald die Verbindung steht, prüfen Sie, dass Sie nicht mehr geöffnet haben als beabsichtigt: Führen Sie das kostenlose Skript local-ai-checkup aus (liest nur, sendet nichts vom Rechner weg). Es meldet die Bind-Adresse von Ollama, veröffentlichte Docker-Ports und Versionen. Siehe auch Ist mein Ollama offen im Netz?
MV2 von Munim, Inc. bietet einen lokalen KI-Gesundheitscheck für 49 US-Dollar für einen Rechner an, oder einen Check für kleine Büros für 199 US-Dollar für bis zu 5 Rechner oder einen gemeinsam genutzten Ollama-, Open-WebUI- oder n8n-Server. Sie erhalten einen schriftlichen Bericht darüber, was offen, riskant oder langsam ist und was Sie zuerst beheben sollten, mit genauen Befehlen für Ihr Betriebssystem. Der Bericht ist auf Englisch. Beispielbericht ansehen (Englisch). 49 $ zahlen oder 199 $ zahlen über Stripe, und senden Sie dann an munimversion2@gmail.com die Ausgabe von python3 local_ai_checkup.py --json, Ihr Betriebssystem und wofür Sie es nutzen. MV2 fragt nie nach Passwörtern, Schlüsseln oder Fernzugriff.