Local Ollama AI agent connection issue

Questions
, ,
1

Describe the problem/error/question

Hi,

I’m experiencing a strange issue on Ollama with latest released version of Ollama and n8n.

My setup is as following

[auto-hosted n8n server docker stack]

  • n8n_container
  • squid_proxy (for whitelisting and logging networks access)

[ dedicated server with GPU (cloud)]

  • ollama_container
  • http://<dedicated_server>:11434/api/tags and /api/chat works correctly with curl on the my local host and also in the n8n_container .
  • query to any model on the dedicated server also works correctly with http request node in a n8n workflow
  • http://<dedicated_server>:11434 connection seems ok when adding as a n8n Ollama credential
  • i’ve a “Problem in node ‘AI Agent‘ - fetch failed” if i try to call this ollama instance from any AI node inside a workflow or any chat module in n8n

Thanks you for any help that could solve this problem

Please share your 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”
}
}

Share the output returned by the last node

Problem in node ‘AI Agent‘ - fetch failed

Information on your n8n setup

  • n8n version: 2.20.6
  • Database : SQLite
  • n8n EXECUTIONS_PROCESS setting (default: own, main): default
  • Running n8n via (Docker, npm, n8n cloud, desktop app): docker / auto-hosted
  • Operating system: Ubuntu 26.4
2

What’s actually happening

fetch failed is a transport-level error (TCP/DNS/proxy), not an Ollama error. Your evidence proves Ollama is healthy:

  • curl from the host and from inside n8n_container works
  • the HTTP Request node works to the same :11434

So the model, the port, and the network path all work. Only the Ollama Chat Model (LangChain) node fails. That narrows it to one thing: those two node types use different HTTP clients.

  • The HTTP Request node (and curl) use n8n’s proxy-aware client, which honors HTTP_PROXY/HTTPS_PROXY/NO_PROXY. So it routes out through squid_proxy, which is whitelisted, and succeeds.
  • The LangChain Ollama node uses Node’s native fetch (undici). undici does not read the proxy env vars by default. So it tries to connect directly to <dedicated_server>:11434, squid never sees it, and the whitelist/egress rule blocks the direct connection → fetch failed.

That’s the whole thing: the squid whitelist is doing exactly its job, and the LangChain node is the one client that bypasses the proxy.

Two ways to fix it

A. Let the LangChain node’s direct connection out (simplest). Add a firewall/egress rule allowing n8n_container → <dedicated_server>:11434 directly (not via squid), and add the host to NO_PROXY so nothing tries to proxy it:
NO_PROXY=fbhbxxxxxx.ikexpress.com,localhost,127.0.0.1

B. Force undici through squid instead. Keep egress locked to the proxy, but make the LangChain node’s fetch use it. Recent n8n versions wire a global undici ProxyAgent from the proxy env vars, older ones don’t. So set:
HTTP_PROXY=http://squid_proxy:3128
HTTPS_PROXY=http://squid_proxy:3128
and confirm your n8n build actually applies it to LangChain nodes (test after restart). If it still fails, you’re on a version that doesn’t proxy undici, so fall back to option A.

Quick way to confirm the theory

Temporarily allow the n8n container direct egress to the dedicated server (bypass squid for that host). If the AI Agent immediately starts working, it’s confirmed the proxy/undici mismatch, and you pick A or B as your permanent path.

Two smaller things to rule out while you’re in there

  • Credential Base URL: must be http://<dedicated_server>:11434 with scheme and port, no trailing slash. The credential “test” is lenient, so double-check the saved value.
  • “think”: true: only works on a thinking-capable model + recent n8n. Turn it off first while debugging so it can’t mask the real error, then re-enable.
3

Welcome @codeyourweb!

The key thing here: the AI Agent node uses the Ollama credential’s base URL differently than the HTTP Request node. The fetch failed with no further error usually points to one of two things in your setup:

  1. Squid proxy intercepting the connection - AI nodes in n8n make streaming requests, and if your squid proxy is configured to whitelist only specific endpoints or doesn’t support SSE/chunked transfer, it will silently drop the connection. Try temporarily bypassing the proxy by setting NO_PROXY=<dedicated_server_ip> in your n8n container’s environment variables and re-testing the AI Agent node.

  2. Credential URL format - Make sure the Ollama credential Base URL is exactly http://<dedicated_server>:11434 with no trailing slash. The credential test is more lenient than the actual node connection.

Also worth checking: run docker exec -it n8n_container curl http://<dedicated_server>:11434/api/tags from inside the n8n container to confirm the direct path resolves correctly without going through squid.

4

Hi,

The problem is indeed linked to the proxification. i confirm it works by adding my dedicated server to the NO_PROXY list). All works correctly where i remove the squid container and when n8n directly request my ollama server.

About th “B” scenario:

Here are my proxy variables in the n8n container:

- 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

In the squid container

When i curl / http node request:

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

With the AI node HTTP call:



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

Do you think something could be done to keep the proxification ?

5

Nice, that confirms it. One thing worth pointing out though: read your two squid lines carefully, because they’re telling a more specific story than “the AI node bypasses the proxy.”

CONNECT …:11434 TCP_DENIED/403 ← curl / HTTP Request test
GET http://…:11434/api/tags TCP_MISS/200 HIER_DIRECT ← AI node

  • The 403 is only on the CONNECT. Squid ships with http_access deny CONNECT !SSL_ports, and 11434 isn’t in SSL_ports, so any client that tries to tunnel (TLS / https_proxy) to that port gets denied. That’s your curl test, not the node.
  • The AI node’s request is a plain forward-proxied GET and it already went through squid and returned 200 (HIER_DIRECT). So the LangChain node can live behind squid. It’s not the client that can’t be proxied.

So yes, you can keep the proxy. Two things to close it out:

  1. Let squid stop 403ing 11434. Add a dedicated ACL so nothing to that port gets denied, whether it’s a GET or a CONNECT. In squid.conf, above the default http_access deny CONNECT !SSL_ports line:

squid
acl ollama_port port 11434
http_access allow CONNECT ollama_port

(Or just add acl SSL_ports port 11434.) Your plain GETs already pass, so this only matters if the node ever tunnels, but it removes the last source of a silent 403.

  1. Confirm the actual inference call reaches squid, not just /api/tags. /api/tags is the credential/model-list check, it’s a trivial GET. The thing that was failing is the streaming chat call. Tail squid and fire the agent:

docker logs -f squid_container

then run the AI Agent node once

You want to see a line like POST http://…:11434/api/chat (or /api/generate) come through with TCP_MISS/200 HIER_DIRECT. If it does, you’re done, proxy stays and the agent works. If /api/tags shows up in squid but the POST never does, then that specific call is on undici bypassing the proxy, and you’re on an n8n build that doesn’t apply the global ProxyAgent to LangChain’s fetch. In that case your options are to bump n8n to a version that wires HTTP(S)_PROXY into undici, or keep the host in NO_PROXY as the pragmatic fallback (which you’ve proven works).

Quick housekeeping while you test: keep “think”: true off so a thinking-capable-model error can’t masquerade as the transport error, and re-check the saved credential Base URL is exactly http://:11434, no trailing slash.