Problème de connexion avec l'agent Ollama AI local

Décrivez le problème/l’erreur/la question

Bonjour,

J’éprouve un problème étrange avec Ollama utilisant la dernière version publiée d’Ollama et n8n.

Ma configuration est la suivante

[pile docker serveur n8n auto-hébergée]

  • conteneur n8n
  • proxy squid (pour la liste blanche et la journalisation de l’accès réseau)

[ serveur dédié avec GPU (cloud)]

  • conteneur ollama
  • http://<serveur_dédié>:11434/api/tags et /api/chat fonctionnent correctement avec curl sur mon hôte local et aussi dans le conteneur n8n.
  • les requêtes vers n’importe quel modèle sur le serveur dédié fonctionnent également correctement avec le nœud de requête HTTP dans un workflow n8n
  • la connexion http://<serveur_dédié>:11434 semble correcte lors de l’ajout comme credential Ollama dans n8n
  • j’obtiens une erreur « Problème dans le nœud ‘AI Agent’ - fetch failed » si j’essaie d’appeler cette instance ollama à partir de n’importe quel nœud IA à l’intérieur d’un workflow ou de n’importe quel module de chat dans n8n

Merci de votre aide pour résoudre ce problème

Veuillez partager votre 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”
}
}

Partagez la sortie retournée par le dernier nœud

Problème dans le nœud ‘AI Agent’ - fetch failed

Informations sur votre configuration n8n

  • version n8n : 2.20.6
  • Base de données : SQLite
  • paramètre n8n EXECUTIONS_PROCESS (par défaut : own, main) : par défaut
  • Exécution de n8n via (Docker, npm, n8n cloud, application de bureau) : docker / auto-hébergée
  • Système d’exploitation : Ubuntu 26.4

Ce qui se passe réellement

fetch failed est une erreur au niveau du transport (TCP/DNS/proxy), pas une erreur Ollama. Vos preuves montrent qu’Ollama fonctionne correctement :

  • curl depuis l’hôte et depuis l’intérieur de n8n_container fonctionne
  • le nœud HTTP Request fonctionne sur le même :11434

Donc le modèle, le port et le chemin réseau fonctionnent tous. Seul le nœud Ollama Chat Model (LangChain) échoue. Cela réduit le problème à une seule chose : ces deux types de nœud utilisent des clients HTTP différents.

  • Le nœud HTTP Request (et curl) utilisent le client compatible proxy de n8n, qui respecte HTTP_PROXY/HTTPS_PROXY/NO_PROXY. Il route donc via squid_proxy, qui est autorisé, et réussit.
  • Le nœud LangChain Ollama utilise la fonction fetch native de Node (undici). undici ne lit pas les variables d’environnement proxy par défaut. Il essaie donc de se connecter directement à
    <dedicated_server>:11434, squid ne le voit jamais, et la règle de whitelist/sortie bloque la connexion directe → fetch failed.

C’est tout : le whitelist squid fait exactement son travail, et le nœud LangChain est le seul client qui contourne le proxy.

Deux façons de corriger

A. Autoriser la connexion directe du nœud LangChain (la plus simple). Ajoutez une règle de firewall/sortie permettant n8n_container →
<dedicated_server>:11434 directement (pas via squid), et ajoutez l’hôte à NO_PROXY pour que rien n’essaie de le proxifier :
NO_PROXY=fbhbxxxxxx.ikexpress.com,localhost,127.0.0.1

B. Forcer undici via squid à la place. Gardez la sortie verrouillée au proxy, mais faites en sorte que la fonction fetch du nœud LangChain l’utilise. Les versions récentes de n8n câblent un ProxyAgent undici global à partir des variables d’environnement proxy, les anciennes non. Définissez donc :
HTTP_PROXY=http://squid_proxy:3128
HTTPS_PROXY=http://squid_proxy:3128
et confirmez que votre build n8n l’applique réellement aux nœuds LangChain (testez après redémarrage). Si cela échoue toujours, vous êtes sur une version qui ne proxifie pas undici, donc revenez à l’option A.

Façon rapide de confirmer la théorie

Autorisez temporairement le conteneur n8n à une sortie directe vers le serveur dédié (contournez squid pour cet hôte). Si l’Agent IA commence immédiatement à fonctionner, c’est confirmé : c’est une incompatibilité proxy/undici, et vous choisissez A ou B comme votre solution permanente.

Deux petites choses à vérifier pendant que vous y êtes

  • Credential Base URL : doit être http://
    <dedicated_server>:11434 avec schéma et port, pas de barre oblique à la fin. Le test d’identification est indulgent, donc vérifiez bien la valeur enregistrée.
  • « think »: true : ne fonctionne que sur un modèle capable de penser + n8n récent. Désactivez-le d’abord en dépannant pour qu’il ne puisse pas masquer l’erreur réelle, puis réactivez-le.

Bienvenue @codeyourweb !

Voici le point clé : le nœud AI Agent utilise l’URL de base des identifiants Ollama différemment du nœud HTTP Request. L’erreur fetch failed sans détail supplémentaire pointe généralement vers l’une de ces deux choses dans votre configuration :

  1. Proxy Squid interceptant la connexion - Les nœuds IA dans n8n effectuent des requêtes en streaming, et si votre proxy squid est configuré pour n’autoriser que des endpoints spécifiques ou ne supporte pas SSE/chunked transfer, il fermera silencieusement la connexion. Essayez de contourner temporairement le proxy en définissant NO_PROXY=<dedicated_server_ip> dans les variables d’environnement du conteneur n8n et en retestant le nœud AI Agent.

  2. Format d’URL des identifiants - Assurez-vous que l’URL de base des identifiants Ollama est exactement http://<dedicated_server>:11434 sans slash à la fin. Le test d’identifiants est plus permissif que la connexion réelle du nœud.

À vérifier également : exécutez docker exec -it n8n_container curl http://<dedicated_server>:11434/api/tags depuis l’intérieur du conteneur n8n pour confirmer que le chemin direct se résout correctement sans passer par squid.

Bonjour,

Le problème est effectivement lié à la proxification. Je confirme que cela fonctionne en ajoutant mon serveur dédié à la liste NO_PROXY). Tout fonctionne correctement quand je supprime le conteneur squid et quand n8n demande directement mon serveur ollama.

Concernant le scénario « B » :

Voici mes variables de proxy dans le conteneur n8n :

- HTTP_PROXY=http://squid_conainer_name:3128
- HTTPS_PROXY=http://squid_container_name:3128         
- NO_PROXY=localhost,127.0.0.1,172.16.1.30,172.16.1.0/24,10.24.0.0/16
       

Dans le conteneur squid

Quand j’utilise curl / requête HTTP node :

squid           | 1783602201.302      0 172.16.1.3 TCP_DENIED/403 3453 CONNECT frhbxxxxxxxx.ikexpress.com:11434 - HIER_NONE/- text/html
 

Avec l’appel HTTP du nœud IA :



squid           | 1783602250.308     35 172.16.1.3 TCP_MISS/200 5322 GET http://frhbxxxxxxxx.ikexpress.com:11434/api/tags - HIER_DIRECT/<REMOTE_IP-> application/json

Pensez-vous qu’il serait possible de faire quelque chose pour maintenir la proxification ?

Bien, ça le confirme. Une chose mérite d’être soulignée cependant : relisez attentivement vos deux lignes squid, car elles racontent une histoire plus spécifique que « le nœud IA contourne le proxy ».

CONNECT …:11434 TCP_DENIED/403 ← test de requête curl / HTTP
GET http://…:11434/api/tags TCP_MISS/200 HIER_DIRECT ← nœud IA

  • Le 403 ne porte que sur le CONNECT. Squid est livré avec http_access deny CONNECT !SSL_ports, et 11434 ne figure pas dans SSL_ports, donc tout client qui essaie de tunneliser (TLS / https_proxy) vers ce port se voit refuser l’accès. C’est votre test curl, pas le nœud.
  • La requête du nœud IA est un GET simple en proxy direct et elle a déjà traversé squid et retourné 200 (HIER_DIRECT). Le nœud LangChain peut donc rester derrière squid. Ce n’est pas le client qui ne peut pas être proxifié.

Donc oui, vous pouvez garder le proxy. Deux choses pour conclure :

  1. Empêchez squid de refuser 11434 avec un 403. Ajoutez une ACL dédiée pour que rien vers ce port ne soit refusé, qu’il s’agisse d’un GET ou d’un CONNECT. Dans squid.conf, au-dessus de la ligne par défaut http_access deny CONNECT !SSL_ports :

squid
acl ollama_port port 11434
http_access allow CONNECT ollama_port

(Ou ajoutez simplement acl SSL_ports port 11434.) Vos GET simples passent déjà, donc cela n’importe que si le nœud tunnelise un jour, mais cela élimine la dernière source d’un 403 silencieux.

  1. Confirmez que l’appel d’inférence réel atteint squid, pas seulement /api/tags. /api/tags est la vérification des identifiants/liste de modèles, c’est un GET trivial. Ce qui échouait, c’est l’appel de chat en streaming. Consultez les journaux squid et exécutez l’agent :

docker logs -f squid_container

puis exécutez une fois le nœud Agent IA

Vous devriez voir une ligne comme POST http://…:11434/api/chat (ou /api/generate) passer avec TCP_MISS/200 HIER_DIRECT. Si c’est le cas, vous avez terminé, le proxy reste et l’agent fonctionne. Si /api/tags apparaît dans squid mais que le POST n’apparaît jamais, c’est que cet appel spécifique est sur undici contournant le proxy, et vous êtes sur une version n8n qui n’applique pas le ProxyAgent global à la requête fetch de LangChain. Dans ce cas, vos options sont de mettre à jour n8n vers une version qui connecte HTTP(S)_PROXY à undici, ou garder l’hôte dans NO_PROXY comme solution pragmatique de secours (ce que vous avez prouvé fonctionner).

Un petit rangement pendant que vous testez : gardez « think »: true désactivé pour qu’une erreur d’un modèle capable de réflexion ne puisse pas se faire passer pour l’erreur de transport, et revérifiez que l’URL de base des identifiants sauvegardés est exactement http://
<hôte

:11434, sans barre oblique finale.

Désolé pour cette réponse tardive, je n’avais pas eu le temps de la résoudre avant. Merci beaucoup @Michael_Frostbutter, tu avais raison !