本地 Ollama AI 代理連接問題

描述問題/錯誤/問題

嗨,

我在使用最新版本的 Ollama 和 n8n 時遇到了奇怪的問題。

我的設置如下

[自託管 n8n 伺服器 docker 堆棧]

  • n8n_container
  • squid_proxy(用於白名單和記錄網路存取)

[ 配備 GPU 的專用伺服器(雲端)]

  • ollama_container
  • http://<dedicated_server>:11434/api/tags 和 /api/chat 在我的本機主機和 n8n_container 中使用 curl 時工作正常。
  • 查詢專用伺服器上的任何模型也可以正確使用 n8n 工作流中的 http 請求節點
  • 添加為 n8n Ollama 憑據時,http://<dedicated_server>:11434 連線似乎沒問題
  • 如果我嘗試從工作流中的任何 AI 節點或 n8n 中的任何聊天模組呼叫此 ollama 執行個體,我會收到「節點 ‘AI Agent’ 出錯 - fetch 失敗」

感謝您的幫助,希望能解決此問題

請分享您的工作流

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

分享最後一個節點返回的輸出

節點 ‘AI Agent’ 出錯 - fetch 失敗

關於您的 n8n 設置的資訊

  • n8n 版本: 2.20.6
  • 資料庫:SQLite
  • n8n EXECUTIONS_PROCESS 設置(預設值:own, main):預設
  • 執行 n8n 的方式(Docker、npm、n8n cloud、桌面應用程式):docker / 自託管
  • 作業系統:Ubuntu 26.4

實際上發生了什麼

fetch failed 是傳輸層級的錯誤(TCP/DNS/proxy),而非 Ollama 錯誤。你的證據證明 Ollama 狀態良好:

  • 從主機和 n8n_container 內部的 curl 都可以運作
  • HTTP Request 節點可以連接到相同的 :11434

所以模型、連接埠和網路路徑都沒問題。只有 Ollama Chat Model(LangChain)節點失敗。這將問題縮小到一個原因:這兩種節點類型使用不同的 HTTP 客戶端。

  • HTTP Request 節點(和 curl)使用 n8n 的代理感知客戶端,它遵守 HTTP_PROXY/HTTPS_PROXY/NO_PROXY。所以它通過 squid_proxy 路由,這是被列入白名單的,因此成功。
  • LangChain Ollama 節點使用 Node 的原生 fetch(undici)。undici 預設不讀取代理環境變數。所以它試圖直接連接到 <dedicated_server>:11434,squid 看不到,白名單/出站規則阻止直接連接 → fetch failed。

整個情況就是這樣:squid 白名單在做它該做的工作,而 LangChain 節點是唯一繞過代理的客戶端。

兩種修復方式

A. 允許 LangChain 節點的直接連接(最簡單)。新增防火牆/出站規則允許 n8n_container → <dedicated_server>:11434 直接連接(不經 squid),並將該主機新增到 NO_PROXY 以防任何東西試圖代理它:
NO_PROXY=fbhbxxxxxx.ikexpress.com,localhost,127.0.0.1

B. 強制 undici 通過 squid。保持出站只能通過代理,但讓 LangChain 節點的 fetch 使用它。最新的 n8n 版本會從代理環境變數配置全域 undici ProxyAgent,舊版本不會。所以設定:
HTTP_PROXY=http://squid_proxy:3128
HTTPS_PROXY=http://squid_proxy:3128
並確認你的 n8n 構建確實將其應用於 LangChain 節點(重啟後測試)。如果仍然失敗,表示你在不代理 undici 的版本上,改用選項 A。

快速確認理論的方法

暫時允許 n8n 容器直接出站到專用伺服器(為該主機繞過 squid)。如果 AI Agent 立即開始運作,就確認了代理/undici 不匹配的問題,你選擇 A 或 B 作為永久方案。

調試時要確認的兩個較小事項

  • 認證基底 URL:必須是 http://<dedicated_server>:11434,包含協定和連接埠,無尾部斜線。認證「測試」較為寬鬆,所以雙檢保存的值。
  • 「think」: true:只在能思考的模型 + 最新 n8n 上運作。調試時先關閉它,以防它掩蓋真正的錯誤,然後重新啟用。

歡迎 @codeyourweb

這裡的關鍵是:AI Agent 節點使用 Ollama 認證的基礎 URL 的方式與 HTTP Request 節點不同。fetch failed 沒有進一步的錯誤通常指向你的設定中以下兩件事之一:

  1. Squid 代理攔截連線 - n8n 中的 AI 節點進行串流請求,如果你的 squid 代理配置為只列出特定端點或不支援 SSE/分塊傳輸,它會默默地中斷連線。試著通過在 n8n 容器的環境變數中設定 NO_PROXY=<dedicated_server_ip> 來臨時繞過代理,然後重新測試 AI Agent 節點。

  2. 認證 URL 格式 - 確保 Ollama 認證基礎 URL 確實是 http://<dedicated_server>:11434,沒有尾部的斜線。認證測試比實際的節點連線更寬鬆。

也值得檢查:在 n8n 容器內運行 docker exec -it n8n_container curl http://<dedicated_server>:11434/api/tags 來確認直接路徑正確解析,而不經過 squid。

嗨,

這個問題確實與代理化有關。我確認它通過將我的專用伺服器添加到 NO_PROXY 列表中可以正常運作)。當我移除 squid 容器並且 n8n 直接請求我的 ollama 伺服器時,一切都能正常工作。

關於「B」情景:

以下是 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
       

在 squid 容器中

當我 curl / http 節點請求時:

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

使用 AI 節點 HTTP 呼叫時:



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

你認為有什麼辦法可以保持代理化嗎?

不錯,這證實了。不過有一點值得指出:仔細閱讀你的兩行 squid 記錄,因為它們講述的故事比「AI 節點繞過代理」更具體。

CONNECT …:11434 TCP_DENIED/403 ← curl / HTTP 請求測試
GET http://…:11434/api/tags TCP_MISS/200 HIER_DIRECT ← AI 節點

  • 403 只出現在 CONNECT 上。Squid 預設配置是 http_access deny CONNECT !SSL_ports,而 11434 不在 SSL_ports 中,所以任何嘗試通道化(TLS / https_proxy)到該連接埠的用戶端都會被拒絕。那是你的 curl 測試,不是節點。
  • AI 節點的請求是純轉發代理的 GET,它已經通過 squid 並返回 200(HIER_DIRECT)。所以 LangChain 節點可以在 squid 後面運行。不是用戶端無法通過代理。

所以是的,你可以保留代理。有兩件事要完成:

  1. 讓 squid 停止對 11434 返回 403。新增一個專用 ACL,使得對該連接埠的任何請求都不會被拒絕,無論是 GET 還是 CONNECT。在 squid.conf 中,放在預設的 http_access deny CONNECT !SSL_ports 行之前:

squid
acl ollama_port port 11434
http_access allow CONNECT ollama_port

(或者只需新增 acl SSL_ports port 11434。)你的純 GET 已經通過了,所以這只在節點嘗試通道化時才有問題,但它消除了最後的隱性 403 來源。

  1. 確認實際推論呼叫到達 squid,而不僅僅是 /api/tags。/api/tags 是憑證/模型清單檢查,這是個簡單的 GET。失敗的是流式聊天呼叫。追蹤 squid 日誌並執行代理:

docker logs -f squid_container

然後執行一次 AI Agent 節點

你想看到類似 POST http://…:11434/api/chat(或 /api/generate)的行通過,顯示 TCP_MISS/200 HIER_DIRECT。如果有的話,就完成了,代理保留並且代理有效。如果 /api/tags 出現在 squid 中但 POST 從未出現,那麼該特定呼叫是在 undici 繞過代理,而你使用的是不會將全域 ProxyAgent 套用到 LangChain 提取的 n8n 版本。在這種情況下,你的選項是升級 n8n 到將 HTTP(S)_PROXY 連線到 undici 的版本,或者將主機保留在 NO_PROXY 中作為務實的後備方案(你已經證明這可行)。

測試時的快速整理:保持「think」:true 關閉,這樣具有思考能力的模型錯誤就不會偽裝成傳輸錯誤,並重新檢查儲存的憑證 Base URL 是否完全是 http://

:11434,沒有尾部斜杠。

抱歉這麼晚才回覆,之前我沒有時間去解決這個問題。非常感謝你 @Michael_Frostbutter,你說得沒錯!