Verbindungsproblem mit lokalem Ollama AI-Agent

Fragen
, ,
1

Problem/Fehler/Frage beschreiben

Hi,

Ich habe ein seltsames Problem mit Ollama mit der neuesten veröffentlichten Version von Ollama und n8n.

Mein Setup sieht wie folgt aus

[selbst gehosteter n8n-Server Docker-Stack]

  • n8n_container
  • squid_proxy (für Whitelisting und Logging von Netzwerkzugriffen)

[ dedizierter Server mit GPU (Cloud)]

  • ollama_container
  • http://<dedicated_server>:11434/api/tags und /api/chat funktionieren korrekt mit curl auf meinem lokalen Host und auch im n8n_container .
  • Abfragen an ein beliebiges Modell auf dem dedizierten Server funktionieren auch korrekt mit HTTP-Request-Node in einem n8n-Workflow
  • Die Verbindung zu http://<dedicated_server>:11434 scheint in Ordnung zu sein, wenn ich sie als n8n Ollama-Anmeldedaten hinzufüge
  • Ich erhalte einen „Problem in node ‘AI Agent’ - fetch failed"-Fehler, wenn ich versuche, diese Ollama-Instanz von einem beliebigen AI-Node innerhalb eines Workflows oder eines Chat-Moduls in n8n aufzurufen

Danke für jede Hilfe, die dieses Problem lösen könnte

Bitte teilen Sie Ihren Workflow

{
“nodes”: [
{
“parameters”: {},
“type”: “n8n-nodes-base.manualTrigger”,
“typeVersion”: 1,
“position”: [
0,
16
],
“id”: “cc9cc806-e14a-458d-afc4-76dcd2a560a7”,
“name”: “When clicking ‘Execute workflow’”
},
{
“parameters”: {
“method”: “POST”,
“url”: “http://fbhbxxxxxx.ikexpress.com:11434/api/chat”,
“sendBody”: true,
“specifyBody”: “json”,
“jsonBody”: “{\n “model”: “qwen3.5:9b”,\n “messages”: [\n {\n “role”: “user”,\n “content”: “quelle est la circonférence de la Terre?”\n }\n ],\n “stream”: false\n}”,
“options”: {}
},
“type”: “n8n-nodes-base.httpRequest”,
“typeVersion”: 4.4,
“position”: [
208,
16
],
“id”: “161403d3-fd98-41ea-9736-b4ee1435dff5”,
“name”: “HTTP Request”
},
{
“parameters”: {
“options”: {}
},
“type”: “@n8n/n8n-nodes-langchain.chatTrigger”,
“typeVersion”: 1.4,
“position”: [
192,
192
],
“id”: “fdaf2809-b580-4937-854a-0927e2b0e32e”,
“name”: “When chat message received”,
“webhookId”: “d76a61ad-3cad-4d5c-8ade-17f5fbd64138”
},
{
“parameters”: {
“options”: {}
},
“type”: “@n8n/n8n-nodes-langchain.agent”,
“typeVersion”: 3.1,
“position”: [
480,
192
],
“id”: “f47ddff9-d2a6-43cb-b883-7635b7610f7e”,
“name”: “AI Agent”
},
{
“parameters”: {
“model”: “qwen3.5:9b”,
“options”: {
“think”: true
}
},
“type”: “@n8n/n8n-nodes-langchain.lmChatOllama”,
“typeVersion”: 1,
“position”: [
320,
400
],
“id”: “78e04bfc-8a40-4f5c-a43b-972d195f6b5a”,
“name”: “Ollama Chat Model”,
“credentials”: {
“ollamaApi”: {
“id”: “PLO1mFbqxhIeusv5”,
“name”: “Ollama fbhbxxxxxx.ikexpress.com”
}
}
}
],
“connections”: {
“When clicking ‘Execute workflow’”: {
“main”: [
[
{
“node”: “HTTP Request”,
“type”: “main”,
“index”: 0
}
]
]
},
“When chat message received”: {
“main”: [
[
{
“node”: “AI Agent”,
“type”: “main”,
“index”: 0
}
]
]
},
“Ollama Chat Model”: {
“ai_languageModel”: [
[
{
“node”: “AI Agent”,
“type”: “ai_languageModel”,
“index”: 0
}
]
]
}
},
“pinData”: {},
“meta”: {
“templateCredsSetupCompleted”: true,
“instanceId”: “b3dc2013ef538fd8ebfffd1dbb769a21f0519091604fee835d3a54dcbb102237”
}
}

Von dem letzten Node zurückgegebene Ausgabe teilen

Problem in node ‘AI Agent’ - fetch failed

Informationen zu Ihrem n8n-Setup

  • n8n-Version: 2.20.6
  • Datenbank: SQLite
  • n8n EXECUTIONS_PROCESS-Einstellung (Standard: own, main): Standard
  • n8n wird ausgeführt über (Docker, npm, n8n cloud, Desktop-App): docker / selbst gehostet
  • Betriebssystem: Ubuntu 26.4
2

Was tatsächlich passiert

fetch failed ist ein Transport-Level-Fehler (TCP/DNS/Proxy), kein Ollama-Fehler. Deine Beweise zeigen, dass Ollama gesund ist:

  • curl vom Host und von innen aus n8n_container funktioniert
  • der HTTP Request Node funktioniert auf dem gleichen :11434

Also funktionieren das Modell, der Port und der Netzwerkpfad. Nur der Ollama Chat Model (LangChain) Node schlägt fehl. Das grenzt es auf eines ein: diese zwei Node-Typen nutzen unterschiedliche HTTP-Clients.

  • Der HTTP Request Node (und curl) nutzen n8ns proxy-aware Client, der HTTP_PROXY/HTTPS_PROXY/NO_PROXY berücksichtigt. So routet er durch squid_proxy, was whitelisted ist, und funktioniert.
  • Der LangChain Ollama Node nutzt Nodes natives fetch (undici). undici liest die Proxy-Umgebungsvariablen standardmäßig nicht. So versucht er direkt zu
    <dedicated_server>:11434 zu verbinden, squid sieht es nie, und die Whitelist/Egress-Regel blockiert die direkte Verbindung → fetch failed.

Das ist das ganze Problem: die squid Whitelist macht genau ihren Job, und der LangChain Node ist der eine Client, der den Proxy umgeht.

Zwei Wege zum Beheben

A. Lass die direkte Verbindung des LangChain Nodes zu (am einfachsten). Füge eine Firewall/Egress-Regel hinzu, die n8n_container → <dedicated_server>:11434 direkt erlaubt (nicht via squid), und füge den Host zu NO_PROXY hinzu, damit nichts versucht, es zu proxyen:
NO_PROXY=fbhbxxxxxx.ikexpress.com,localhost,127.0.0.1

B. Erzwinge undici durch squid. Halte Egress zum Proxy gesperrt, aber mach den fetch des LangChain Nodes so, dass er ihn nutzt. Neuere n8n Versionen verdrahten einen globalen undici ProxyAgent aus den Proxy-Umgebungsvariablen, ältere nicht. Also setz:
HTTP_PROXY=http://squid_proxy:3128
HTTPS_PROXY=http://squid_proxy:3128
und bestätige, dass dein n8n Build das tatsächlich auf LangChain Nodes anwendet (teste nach Neustart). Wenn es immer noch fehlschlägt, bist du auf einer Version, die undici nicht proxyet, also geh auf Option A zurück.

Schnelle Weise, die Theorie zu bestätigen

Erlaube dem n8n Container temporär direkten Egress zum dedizierten Server (umgehe squid für diesen Host). Wenn der AI Agent sofort funktioniert, ist es bestätigt, dass es ein Proxy/undici Mismatch ist, und du wählst A oder B als dinen dauerhaften Weg.

Zwei kleinere Dinge, die du ausschließen solltest, während du dort bist

  • Credential Base URL: muss http://<dedicated_server>:11434 mit Schema und Port sein, kein Schrägstrich am Ende. Der Credential „Test
3

Willkommen @codeyourweb!

Das Wichtigste hier: Der AI Agent Node nutzt die Basis-URL der Ollama-Anmeldedaten anders als der HTTP Request Node. Der fetch failed ohne weitere Fehlermeldung deutet normalerweise auf eines von zwei Dingen in deiner Einrichtung hin:

  1. Squid Proxy fängt die Verbindung ab - AI Nodes in n8n machen Streaming-Anfragen, und wenn dein Squid Proxy so konfiguriert ist, dass er nur bestimmte Endpunkte auf die Whitelist setzt, oder SSE/Chunked Transfer nicht unterstützt, wird die Verbindung stillschweigend beendet. Versuche, den Proxy vorübergehend zu umgehen, indem du NO_PROXY=<dedicated_server_ip> in den Umgebungsvariablen deines n8n Containers setzt und den AI Agent Node erneut testest.

  2. Format der Anmeldedaten-URL - Stelle sicher, dass die Basis-URL der Ollama-Anmeldedaten genau http://<dedicated_server>:11434 ist, ohne nachfolgenden Schrägstrich. Der Anmeldedatentest ist toleranter als die tatsächliche Node-Verbindung.

Auch überprüfenswert: Führe docker exec -it n8n_container curl http://<dedicated_server>:11434/api/tags von innen im n8n Container aus, um zu bestätigen, dass der direkte Pfad ohne Umweg über Squid korrekt aufgelöst wird.

4

Hallo,

Das Problem ist tatsächlich mit der Proxifizierung verbunden. Ich bestätige, dass es funktioniert, wenn ich meinen dedizierten Server zur NO_PROXY-Liste hinzufüge). Alles funktioniert korrekt, wenn ich den squid-Container entferne und n8n direkt meinen ollama-Server anfrage.

Zum „B

5

Schön, dass das bestätigt wird. Eine Sache, die es wert ist, hingewiesen zu werden: Lesen Sie Ihre zwei Squid-Zeilen sorgfältig durch, denn sie erzählen eine spezifischere Geschichte als „der AI-Knoten umgeht den Proxy

6

Entschuldigung für die späte Antwort, ich hatte vorher keine Zeit, das zu lösen. Vielen Dank @Michael_Frostbutter, du hattest recht!