Problema de conexão com agente IA Ollama local

Descreva o problema/erro/pergunta

Olá,

Estou enfrentando um problema estranho no Ollama com a versão mais recente lançada do Ollama e n8n.

Minha configuração é a seguinte

[stack docker de servidor n8n auto-hospedado]

  • n8n_container
  • squid_proxy (para lista branca e registro de acesso à rede)

[ servidor dedicado com GPU (nuvem)]

  • ollama_container
  • http://<servidor_dedicado>:11434/api/tags e /api/chat funcionam corretamente com curl no meu host local e também no n8n_container .
  • consulta a qualquer modelo no servidor dedicado também funciona corretamente com o nó de requisição http em um workflow n8n
  • a conexão http://<servidor_dedicado>:11434 parece ok ao adicionar como credencial Ollama do n8n
  • tenho um “Problema no nó ‘AI Agent’ - fetch falhou” se tentar chamar esta instância ollama de qualquer nó IA dentro de um workflow ou qualquer módulo de chat no n8n

Obrigado por qualquer ajuda que possa resolver este problema

Compartilhe seu 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”
}
}

Compartilhe a saída retornada pelo último nó

Problema no nó ‘AI Agent’ - fetch falhou

Informações sobre sua configuração n8n

  • versão n8n: 2.20.6
  • Banco de dados : SQLite
  • configuração n8n EXECUTIONS_PROCESS (padrão: own, main): padrão
  • Executando n8n via (Docker, npm, n8n cloud, aplicativo desktop): docker / auto-hospedado
  • Sistema operacional: Ubuntu 26.4

O que está realmente acontecendo

fetch failed é um erro de nível de transporte (TCP/DNS/proxy), não um erro do Ollama. Sua evidência prova que o Ollama está saudável:

  • curl do host e de dentro do n8n_container funcionam
  • o nó HTTP Request funciona para o mesmo :11434

Então o modelo, a porta e o caminho de rede funcionam. Apenas o nó Ollama Chat Model (LangChain) falha. Isso reduz a uma coisa: esses dois tipos de nós usam clientes HTTP diferentes.

  • O nó HTTP Request (e curl) usam o cliente ciente de proxy do n8n, que honra HTTP_PROXY/HTTPS_PROXY/NO_PROXY. Portanto, ele roteia através do squid_proxy, que está na whitelist, e funciona.
  • O nó Ollama LangChain usa o fetch nativo do Node (undici). undici não lê as variáveis de proxy env por padrão. Portanto, ele tenta conectar diretamente a <dedicated_server>:11434, squid nunca vê, e a regra de whitelist/egress bloqueia a conexão direta → fetch failed.

É só isso: a whitelist do squid está fazendo exatamente seu trabalho, e o nó LangChain é o único cliente que contorna o proxy.

Duas maneiras de corrigir

A. Permitir a conexão direta do nó LangChain (mais simples). Adicione uma regra de firewall/egress permitindo n8n_container → <dedicated_server>:11434 diretamente (não via squid), e adicione o host a NO_PROXY para que nada tente fazer proxy:
NO_PROXY=fbhbxxxxxx.ikexpress.com,localhost,127.0.0.1

B. Forçar undici através do squid. Mantenha o egress bloqueado para o proxy, mas faça o fetch do nó LangChain usá-lo. Versões recentes do n8n conectam um ProxyAgent undici global das variáveis de proxy env, versões antigas não fazem. Então defina:
HTTP_PROXY=http://squid_proxy:3128
HTTPS_PROXY=http://squid_proxy:3128
e confirme que sua compilação do n8n realmente o aplica aos nós LangChain (teste após reiniciar). Se ainda falhar, você está em uma versão que não faz proxy de undici, então volte à opção A.

Maneira rápida de confirmar a teoria

Permita temporariamente ao container n8n egress direto para o servidor dedicado (contorne squid para esse host). Se o AI Agent começar a funcionar imediatamente, é confirmado o descasamento proxy/undici, e você escolhe A ou B como seu caminho permanente.

Duas coisas menores para descartar enquanto você está aí

  • Credential Base URL: deve ser http://<dedicated_server>:11434 com scheme e porta, sem barra à direita. O “test” da credential é leniente, então verifique novamente o valor salvo.
  • “think”: true: funciona apenas em um modelo com capacidade de pensamento + n8n recente. Desligue primeiro durante a depuração para que não possa mascarar o erro real, depois reative.

Bem-vindo @codeyourweb!

O ponto chave aqui: o nó AI Agent usa a URL base da credencial do Ollama de forma diferente do nó HTTP Request. O fetch failed sem erro adicional geralmente aponta para uma de duas coisas na sua configuração:

  1. Proxy Squid interceptando a conexão - Nós de AI no n8n fazem requisições de streaming, e se seu proxy squid está configurado para colocar na lista de permissões apenas endpoints específicos ou não suporta SSE/transferência em chunks, ele descartará silenciosamente a conexão. Tente contornar temporariamente o proxy definindo NO_PROXY=<dedicated_server_ip> nas variáveis de ambiente do seu contêiner n8n e testando novamente o nó AI Agent.

  2. Formato de URL da credencial - Certifique-se de que a URL Base da credencial do Ollama seja exatamente http://<dedicated_server>:11434 sem barra final. O teste de credencial é mais tolerante que a conexão do nó atual.

Também vale verificar: execute docker exec -it n8n_container curl http://<dedicated_server>:11434/api/tags de dentro do contêiner n8n para confirmar que o caminho direto é resolvido corretamente sem passar pelo squid.

Oi,

O problema está mesmo ligado à proxificação. Confirmo que funciona adicionando meu servidor dedicado à lista NO_PROXY). Tudo funciona corretamente quando removo o container squid e quando o n8n faz requisições diretamente para meu servidor ollama.

Sobre o cenário “B”:

Aqui estão minhas variáveis de proxy no container 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
       

No container squid

Quando faço curl / requisição com http node:

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

Com a chamada HTTP do node 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

Você acha que algo poderia ser feito para manter a proxificação?

Legal, isso confirma. Uma coisa que vale a pena apontar: leia suas duas linhas de squid com cuidado, porque elas estão contando uma história mais específica do que “o nó de IA ignora o proxy.”

CONNECT …:11434 TCP_DENIED/403 ← teste curl / Requisição HTTP
GET http://…:11434/api/tags TCP_MISS/200 HIER_DIRECT ← nó de IA

  • O 403 é apenas no CONNECT. O Squid vem com http_access deny CONNECT !SSL_ports, e 11434 não está em SSL_ports, então qualquer cliente que tente fazer túnel (TLS / https_proxy) para essa porta é negado. Esse é seu teste curl, não o nó.
  • A requisição do nó de IA é um GET com proxy forward simples e já passou pelo squid e retornou 200 (HIER_DIRECT). Então o nó LangChain pode ficar atrás do squid. Não é o cliente que não pode ser proxiado.

Então sim, você pode manter o proxy. Duas coisas para finalizá-lo:

  1. Deixe o squid parar de negar 11434 com 403. Adicione uma ACL dedicada para que nada para essa porta seja negado, seja um GET ou um CONNECT. Em squid.conf, acima da linha padrão http_access deny CONNECT !SSL_ports:

squid
acl ollama_port port 11434
http_access allow CONNECT ollama_port

(Ou apenas adicione acl SSL_ports port 11434.) Seus GETs simples já passam, então isso só importa se o nó algum dia fizer túnel, mas remove a última fonte de um 403 silencioso.

  1. Confirme que a chamada de inferência real chega ao squid, não apenas /api/tags. /api/tags é a verificação de credencial/lista de modelos, é um GET trivial. A coisa que estava falhando é a chamada de chat com streaming. Monitore squid e dispare o agente:

docker logs -f squid_container

então execute o nó do Agente de IA uma vez

Você quer ver uma linha como POST http://…:11434/api/chat (ou /api/generate) passar com TCP_MISS/200 HIER_DIRECT. Se passar, você terminou, o proxy fica e o agente funciona. Se /api/tags aparecer no squid mas o POST nunca aparecer, então essa chamada específica está no undici ignorando o proxy, e você está em um build n8n que não aplica o ProxyAgent global ao fetch do LangChain. Nesse caso, suas opções são atualizar n8n para uma versão que conecta HTTP(S)_PROXY ao undici, ou manter o host em NO_PROXY como fallback pragmático (que você provou funcionar).

Limpeza rápida enquanto você testa: mantenha “think”: true desativado para que um erro de modelo com capacidade de pensar não possa se disfarçar de erro de transporte, e re-verifique se a URL Base da credencial salva é exatamente http://
não há barra à direita.

Desculpa pela resposta atrasada, não tinha tempo pra resolver isso antes. Muito obrigado @Michael_Frostbutter, você estava certo!