Problema de conexión con el agente de IA Ollama local

Describir el problema/error/pregunta

Hola,

Estoy experimentando un problema extraño en Ollama con la última versión lanzada de Ollama y n8n.

Mi configuración es la siguiente

[pila docker del servidor n8n alojado automáticamente]

  • contenedor n8n
  • proxy squid (para incluir en la lista blanca y registrar acceso a redes)

[servidor dedicado con GPU (nube)]

  • contenedor ollama
  • http://<servidor_dedicado>:11434/api/tags y /api/chat funcionan correctamente con curl en mi host local y también en el contenedor n8n.
  • las consultas a cualquier modelo en el servidor dedicado también funcionan correctamente con nodo de solicitud http en un flujo de trabajo de n8n
  • la conexión a http://<servidor_dedicado>:11434 parece estar bien al agregar credenciales de Ollama en n8n
  • obtengo un error “Problem in node ‘AI Agent’ - fetch failed” si intento llamar a esta instancia de ollama desde cualquier nodo de IA dentro de un flujo de trabajo o cualquier módulo de chat en n8n

Gracias de antemano por cualquier ayuda que pueda resolver este problema

Por favor, comparte tu flujo de trabajo

{
“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”
}
}

Comparte el resultado devuelto por el último nodo

Problem in node ‘AI Agent’ - fetch failed

Información sobre tu configuración de n8n

  • versión de n8n: 2.20.6
  • Base de datos: SQLite
  • configuración de n8n EXECUTIONS_PROCESS (predeterminado: own, main): predeterminado
  • Ejecutando n8n a través de (Docker, npm, n8n cloud, aplicación de escritorio): docker / alojado automáticamente
  • Sistema operativo: Ubuntu 26.4

Lo que realmente está pasando

fetch failed es un error a nivel de transporte (TCP/DNS/proxy), no un error de Ollama. Tu evidencia demuestra que Ollama está saludable:

  • curl desde el host y desde dentro de n8n_container funciona
  • el nodo HTTP Request funciona al mismo :11434

Así que el modelo, el puerto y la ruta de red funcionan. Solo el nodo Ollama Chat Model (LangChain) falla. Eso lo reduce a una cosa: esos dos tipos de nodo usan diferentes clientes HTTP.

  • El nodo HTTP Request (y curl) utilizan el cliente compatible con proxy de n8n, que respeta HTTP_PROXY/HTTPS_PROXY/NO_PROXY. Entonces se enruta a través de squid_proxy, que está en la lista blanca, y tiene éxito.
  • El nodo Ollama de LangChain usa el fetch nativo de Node (undici). undici no lee las variables de entorno del proxy por defecto. Entonces intenta conectarse directamente a <dedicated_server>:11434, squid nunca lo ve, y la regla de lista blanca/egreso bloquea la conexión directa → fetch failed.

Eso es todo: la lista blanca de squid está haciendo exactamente su trabajo, y el nodo LangChain es el único cliente que omite el proxy.

Dos formas de arreglarlo

A. Permitir la conexión directa del nodo LangChain (lo más simple). Agrega una regla de firewall/egreso que permita n8n_container → <dedicated_server>:11434 directamente (no a través de squid), y agrega el host a NO_PROXY para que nada intente proxearlo:
NO_PROXY=fbhbxxxxxx.ikexpress.com,localhost,127.0.0.1

B. Fuerza undici a través de squid en su lugar. Mantén el egreso bloqueado al proxy, pero haz que el fetch del nodo LangChain lo use. Las versiones recientes de n8n conectan un ProxyAgent global de undici desde las variables de entorno del proxy, las antiguas no. Entonces establece:
HTTP_PROXY=http://squid_proxy:3128
HTTPS_PROXY=http://squid_proxy:3128
y confirma que tu compilación de n8n realmente lo aplica a los nodos LangChain (prueba después de reiniciar). Si sigue fallando, estás en una versión que no proxea undici, así que recurre a la opción A.

Forma rápida de confirmar la teoría

Permite temporalmente egreso directo del contenedor n8n al servidor dedicado (omite squid para ese host). Si el AI Agent comienza a funcionar de inmediato, se confirma el desajuste proxy/undici, y eliges A o B como tu ruta permanente.

Dos cosas más pequeñas para descartar mientras estés allí

  • Credential Base URL: debe ser http://<dedicated_server>:11434 con esquema y puerto, sin barra diagonal final. La prueba de credencial es indulgente, así que verifica dos veces el valor guardado.
  • “think”: true: solo funciona en un modelo con capacidad de pensamiento + n8n reciente. Desactívalo primero mientras depuras para que no pueda enmascarar el error real, luego reactívalo.

¡Bienvenido @codeyourweb!

Lo importante aquí es que el nodo AI Agent utiliza la URL base de la credencial Ollama de manera diferente al nodo HTTP Request. El fetch failed sin error adicional generalmente apunta a una de dos cosas en tu configuración:

  1. Proxy Squid interceptando la conexión - Los nodos de IA en n8n realizan solicitudes en streaming, y si tu proxy squid está configurado para incluir en la lista blanca solo endpoints específicos o no admite SSE/transferencia fragmentada, silenciosamente interrumpirá la conexión. Intenta omitir temporalmente el proxy configurando NO_PROXY=<dedicated_server_ip> en las variables de entorno del contenedor n8n y prueba nuevamente el nodo AI Agent.

  2. Formato de URL de credencial - Asegúrate de que la URL Base de la credencial Ollama sea exactamente http://<dedicated_server>:11434 sin barra diagonal al final. La prueba de credencial es más flexible que la conexión real del nodo.

También vale la pena verificar: ejecuta docker exec -it n8n_container curl http://<dedicated_server>:11434/api/tags desde dentro del contenedor n8n para confirmar que la ruta directa se resuelve correctamente sin pasar por squid.

Hola,

El problema está efectivamente vinculado a la proxificación. Lo confirmo: funciona agregando mi servidor dedicado a la lista NO_PROXY). Todo funciona correctamente cuando elimino el contenedor squid y cuando n8n solicita directamente mi servidor ollama.

Sobre el escenario “B”:

Aquí están mis variables de proxy en el contenedor 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
       

En el contenedor squid

Cuando hago curl / solicitud del nodo http:

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

Con la llamada HTTP del nodo AI:



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

¿Crees que se podría hacer algo para mantener la proxificación?

Bien, eso lo confirma. Pero hay algo que vale la pena señalar: lee tus dos líneas de squid con cuidado, porque están contando una historia más específica que “el nodo de IA omite el proxy”.

CONNECT …:11434 TCP_DENIED/403 ← prueba de curl / solicitud HTTP
GET http://…:11434/api/tags TCP_MISS/200 HIER_DIRECT ← nodo de IA

  • El 403 solo está en el CONNECT. Squid viene con http_access deny CONNECT !SSL_ports, y 11434 no está en SSL_ports, así que cualquier cliente que intente hacer un túnel (TLS / https_proxy) a ese puerto recibe una denegación. Esa es tu prueba de curl, no el nodo.
  • La solicitud del nodo de IA es un GET con proxy directo y ya pasó por squid y devolvió 200 (HIER_DIRECT). Así que el nodo de LangChain puede vivir detrás de squid. No es el cliente el que no puede estar proxificado.

Así que sí, puedes mantener el proxy. Dos cosas para cerrarlo:

  1. Haz que squid deje de hacer 403 a 11434. Añade una ACL dedicada para que nada a ese puerto reciba una denegación, ya sea un GET o un CONNECT. En squid.conf, encima de la línea predeterminada http_access deny CONNECT !SSL_ports:

squid
acl ollama_port port 11434
http_access allow CONNECT ollama_port

(O simplemente añade acl SSL_ports port 11434.) Tus GETs simples ya pasan, así que esto solo importa si el nodo alguna vez hace un túnel, pero elimina la última fuente de un 403 silencioso.

  1. Confirma que la llamada de inferencia real llega a squid, no solo /api/tags. /api/tags es la verificación de credencial/lista de modelos, es un GET trivial. Lo que estaba fallando es la llamada de chat con streaming. Monitorea squid e inicia el agente:

docker logs -f squid_container

luego ejecuta el nodo del Agente de IA una vez

Quieres ver una línea como POST http://…:11434/api/chat (o /api/generate) pasar con TCP_MISS/200 HIER_DIRECT. Si sucede, terminaste, el proxy se queda y el agente funciona. Si /api/tags aparece en squid pero el POST nunca lo hace, entonces esa llamada específica está en undici omitiendo el proxy, y estás en una compilación de n8n que no aplica el ProxyAgent global a fetch de LangChain. En ese caso tus opciones son actualizar n8n a una versión que conecte HTTP(S)_PROXY en undici, o mantener el host en NO_PROXY como la solución pragmática (que ya has probado que funciona).

Un poco de limpieza rápida mientras pruebas: mantén “think”: true apagado para que un error de modelo capaz de pensar no pueda enmascararse como el error de transporte, y vuelve a verificar que la URL base de la credencial guardada sea exactamente http://

host:11434, sin barra inclinada final.

Disculpa por esta respuesta tardía, no había tenido tiempo para resolverlo antes. ¡Muchas gracias @Michael_Frostbutter, ¡tenías razón!