n8n Ollama Verbindungsfehler: Reale Lösung für 'Error in sub-node Ollama Qwen3 4B'

Im realen Workflow war der Chat Trigger erfolgreich, während AI Agent und Ollama Qwen3 4B rot fehlschlugen.

Statt den Workflow neu zu bauen, wurde die Ollama-Credential- und Docker-Netzwerkstrecke isoliert.

n8n und Ollama laufen in getrennten Containern. localhost im n8n-Container bezeichnet n8n selbst.

Im gemeinsamen user-defined network löst Docker den Containernamen ollama auf. Die funktionierende Base URL war http://ollama:11434.

Falsch: http://localhost:11434

Richtig: http://ollama:11434

Unser gemeinsames Netzwerk hieß eka-ai. Beide Container müssen Mitglied sein, damit der Hostname ollama aufgelöst wird.

Bei getrennten Netzwerken funktioniert selbst der richtige Hostname nicht.

docker network inspect eka-ai

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

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

Der reale Container-Test lieferte HTTP 200 und fand qwen3:4b.

Wenn dieser Test funktioniert, liegt der Fokus auf Credential und Node-Konfiguration statt Docker-Netzwerk.

docker exec n8n node -e "fetch('http://ollama:11434/api/tags').then(async r=>{console.log('HTTP:',r.status);console.log(await r.text())})"

Die reale Chat-Anfrage lieferte N8N-OLLAMA-BAGLANTISI-BASARILI.

Damit sind n8n→Ollama-Netzwerk, Ollama-Runtime und qwen3:4b-Inferenz gemeinsam geprüft.

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))"

Die funktionierende Credential verwendete http://ollama:11434 und wurde dem Ollama-Qwen3-4B-Sub-Node zugewiesen.

Als Modell blieb qwen3:4b ausgewählt.

Base URL: http://ollama:11434

Model: qwen3:4b

Nach Korrektur von Credential und Docker-Adresse lief derselbe Workflow erneut.

Der reale Screenshot zeigt den Modell-Sub-Node ohne den vorherigen roten Fehler.

Ollama Chat Model an Chat Model, Simple Memory an Memory anschließen.

Bei weiteren Fehlern in den Executions den tatsächlich roten Sub-Node identifizieren.

Nach der Modellkorrektur berechnete der Agent 3478 × 129 über Calculator und lieferte 448662.

Damit funktionieren Inferenz und Tool Calling.

In einem späteren Test waren Ollama und AI Agent grün, während das HTTP Request Tool einen separaten supplyData/execute-Fehler zeigte.

Das ist kein Ollama-Credential-Fehler; der reale Screenshot trennt die Ebenen klar.

Der korrigierte Workflow holte JSONPlaceholder-TODO-Daten und erklärte sie erfolgreich.

Der finale reale Screenshot zeigt die komplette Agent-, Modell-, Memory- und Tool-Kette im Erfolgszustand.

Ollama-Container, Docker-Netzwerk, /api/tags aus n8n, Credential Base URL, Modellname und Execution Logs der Reihe nach prüfen.

Damit lassen sich Netzwerk-, Credential-, Modell- und Toolfehler schnell trennen.

docker ps --filter name='^/ollama$'

docker network inspect eka-ai

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

docker exec ollama ollama list

docker logs --tail 100 ollama