Ubuntu 24.04 Docker Netzwerk Ratgeber: Warum n8n, Ollama und Open WebUI nicht per localhost kommunizieren

Im realen Ubuntu-24.04-Test laufen Ollama, Open WebUI und n8n als getrennte Docker-Container. Das benutzerdefinierte Bridge-Netzwerk eka-ai erlaubt die direkte Kommunikation über Containernamen.

n8n und Open WebUI erreichen Ollama unter http://ollama:11434, während Tests auf dem Host http://127.0.0.1:11434 verwenden.

n8n        → eka-ai → ollama:11434
Open WebUI → eka-ai → ollama:11434
Host       → 127.0.0.1:11434

Benutzerdefinierte Docker-Bridge-Netze bieten Namensauflösung zwischen Containern und eine sauberere Projektisolation. eka-ai fasst die AI-Dienste in einem eigenen Netzwerk zusammen.

Wenn eka-ai noch nicht existiert, mit docker network create anlegen. Existiert es bereits, reicht docker network inspect.

docker network create eka-ai

docker network ls

Das Netzwerk allein genügt nicht; die kommunizierenden Container müssen tatsächlich Mitglied sein. docker network inspect zeigt Container und von Docker vergebene IP-Adressen.

Da sich Container-IP-Adressen ändern können, lieber Docker-DNS-Namen wie ollama statt fest codierter 172.x.x.x-Adressen verwenden.

docker network inspect eka-ai

docker inspect ollama --format '{{json .NetworkSettings.Networks}}'
docker inspect n8n --format '{{json .NetworkSettings.Networks}}'
docker inspect open-webui --format '{{json .NetworkSettings.Networks}}'

Im n8n-Container bezeichnet http://localhost:11434 den n8n-Container selbst, nicht Ollama. Separate Container finden sich deshalb nicht über localhost, nur weil sie auf demselben Docker-Host laufen.

Im gemeinsamen user-defined network löst Docker Containernamen per DNS auf. Bei einem Ollama-Container namens ollama lautet die richtige Adresse http://ollama:11434.

Falsch:  http://localhost:11434

Richtig: http://ollama:11434

Die richtige Adresse hängt davon ab, wo der Client läuft. In der SSH-Shell bezeichnet localhost den Docker-Host. In einem Container gehört localhost zum eigenen Netzwerk-Namespace.

Unser reales Setup nutzte 127.0.0.1:11434 für Hosttests und ollama:11434 für n8n- und Open-WebUI-Integrationen.

curl -sS http://127.0.0.1:11434/api/tags

docker exec n8n node -e "fetch('http://ollama:11434/api/tags').then(r=>r.text()).then(console.log)"

Vor der AI-Agent-Konfiguration haben wir die Verbindung direkt aus dem n8n-Container getestet. n8n erreichte http://ollama:11434/api/tags mit HTTP 200 und fand qwen3:4b.

Anschließend lieferte eine echte /api/chat-Anfrage N8N-OLLAMA-BAGLANTISI-BASARILI. Damit waren spätere Credential- oder Node-Fehler nicht auf das Docker-Netzwerk zurückzuführen.

docker exec n8n node -e "fetch('http://ollama:11434/api/tags').then(r=>r.json()).then(j=>console.log(JSON.stringify(j)))"

docker exec n8n node -e "fetch('http://ollama:11434/api/chat',{method:'POST',headers:{'content-type':'application/json'},body:JSON.stringify({model:'qwen3:4b',messages:[{role:'user',content:'Write only N8N-OLLAMA-BAGLANTISI-BASARILI.'}],stream:false})}).then(r=>r.json()).then(j=>console.log(j.message.content))"

Open WebUI läuft getrennt von Ollama und verwendet deshalb ebenfalls den Docker-Netzwerknamen. Im realen Setup war OLLAMA_BASE_URL=http://ollama:11434 gesetzt.

Damit konnte Open WebUI qwen3:4b sehen, ohne Port 11434 öffentlich zu veröffentlichen.

OLLAMA_BASE_URL=http://ollama:11434

docker network connect eka-ai open-webui
docker network connect eka-ai ollama

Das user-defined network regelt private Containerkommunikation, während Port-Publishing separat kontrolliert wird. Wir banden Ollama 11434, Open WebUI 3000 und n8n 5678 nur an 127.0.0.1.

Öffentliche Benutzer erreichten Open WebUI und n8n über Nginx HTTPS. Die Ollama-API blieb nicht öffentlich.

-p 127.0.0.1:11434:11434

-p 127.0.0.1:3000:8080

-p 127.0.0.1:5678:5678

ss -lntp | grep -E ':11434|:3000|:5678'

Wurde --network eka-ai beim Start vergessen, muss der Container nicht zwingend neu erstellt werden. Docker kann laufende Container an user-defined networks anschließen.

Danach Mitgliedschaft mit inspect, DNS mit getent hosts und schließlich echte HTTP-Erreichbarkeit prüfen.

docker network connect eka-ai n8n

docker network connect eka-ai open-webui

docker network inspect eka-ai

docker exec n8n getent hosts ollama

Zuerst prüfen, ob beide Container im selben user-defined network sind. Dann kontrollieren, ob ollama über Docker DNS aufgelöst wird. Funktioniert DNS, aber HTTP nicht, Zielport und Logs des Dienstes prüfen.

Funktioniert 127.0.0.1:11434 auf dem Host, aber ollama:11434 im n8n-Container nicht, liegt das Problem wahrscheinlich bei Netzwerkmitgliedschaft oder Docker DNS.

docker network inspect eka-ai

docker exec n8n getent hosts ollama

docker exec n8n node -e "fetch('http://ollama:11434/api/tags').then(r=>console.log(r.status)).catch(console.error)"

docker logs --tail 100 ollama

Mit wenigen Befehlen lassen sich die meisten Docker-Netzwerkprobleme prüfen: Netzwerk erstellen oder bestätigen, Container verbinden, Mitgliedschaft inspizieren, DNS testen und eine echte HTTP-Anfrage senden.

Dieses Set fasst das Netzwerkmodell unseres n8n-, Ollama- und Open-WebUI-Stacks zusammen.

docker network create eka-ai

docker network connect eka-ai n8n
docker network connect eka-ai open-webui
docker network connect eka-ai ollama

docker network inspect eka-ai

docker exec n8n getent hosts ollama

docker exec n8n node -e "fetch('http://ollama:11434/api/tags').then(r=>r.text()).then(console.log)"

Ein neu erstellter Container kann healthy sein und trotzdem keine Verbindung zum restlichen AI-Stack haben, wenn --network fehlt. Deshalb nach Updates nicht nur Containerstatus, sondern auch Netzwerkmitgliedschaft prüfen.

Zusätzlich mit ss und docker ps kontrollieren, dass Host-Ports nicht versehentlich auf 0.0.0.0 veröffentlicht wurden. Private Docker-Netze und localhost-only Bindings ergänzen sich.

docker network inspect eka-ai

docker ps --format 'table {{.Names}}\t{{.Ports}}'

ss -lntp | grep -E ':11434|:3000|:5678'