مشكلة في الاتصال بوكيل Ollama AI المحلي

أسئلة
, ,
1

وصف المشكلة/الخطأ/السؤال

مرحبا،

أواجه مشكلة غريبة في Ollama مع أحدث إصدار تم إصداره من Ollama و n8n.

إعدادي كالتالي

[مكدس docker لخادم n8n ذاتي الاستضافة]

  • حاوية n8n
  • squid_proxy (للقائمة البيضاء وتسجيل وصول الشبكة)

[خادم مخصص مع GPU (سحابة)]

  • حاوية ollama
  • http://<dedicated_server>:11434/api/tags و /api/chat يعملان بشكل صحيح مع curl على جهازي المحلي وأيضاً في حاوية n8n.
  • الاستعلام عن أي نموذج على الخادم المخصص يعمل أيضاً بشكل صحيح مع عقدة طلب HTTP في سير عمل n8n
  • يبدو أن اتصال http://<dedicated_server>:10434 بحالة جيدة عند إضافته كبيانات اعتماد Ollama في n8n
  • أتلقى رسالة “Problem in node ‘AI Agent’ - fetch failed” عند محاولة استدعاء هذه النسخة من ollama من أي عقدة ذكاء اصطناعي داخل سير عمل أو أي وحدة دردشة في n8n

شكراً لك على أي مساعدة قد تحل هذه المشكلة

يرجى مشاركة سير العمل الخاص بك

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

شارك الناتج الذي أرجعته العقدة الأخيرة

Problem in node ‘AI Agent’ - fetch failed

معلومات حول إعداد n8n الخاص بك

  • إصدار n8n: 2.20.6
  • قاعدة البيانات: SQLite
  • إعداد n8n EXECUTIONS_PROCESS (افتراضي: own, main): افتراضي
  • تشغيل n8n عبر (Docker, npm, n8n cloud, desktop app): docker / ذاتي الاستضافة
  • نظام التشغيل: Ubuntu 26.4
2

ما يحدث بالفعل

فشل fetch هو خطأ على مستوى النقل (TCP/DNS/proxy)، وليس خطأ Ollama. أدلتك تثبت أن Ollama صحي:

  • curl من المضيف ومن داخل n8n_container يعملان
  • عقدة HTTP Request تعمل على نفس :11434

إذن النموذج والمنفذ ومسار الشبكة جميعها تعمل. فقط عقدة Ollama Chat Model (LangChain) تفشل. هذا يضيق النطاق إلى شيء واحد: هذان النوعان من العقد يستخدمان عملاء HTTP مختلفين.

  • عقدة HTTP Request (و curl) تستخدمان عميل n8n الذي يدرك الوكيل، والذي يحترم HTTP_PROXY/HTTPS_PROXY/NO_PROXY. لذا فهو يوجه عبر squid_proxy، والذي موثق في القائمة البيضاء، وينجح.
  • عقدة LangChain Ollama تستخدم fetch الأصلي في Node (undici). undici لا يقرأ متغيرات بيئة الوكيل بشكل افتراضي. لذا يحاول الاتصال مباشرة بـ \u003cdedicated_server\u003e:11434، لا يراها squid، وقاعدة القائمة البيضاء/الخروج تحجب الاتصال المباشر → فشل fetch.

هذا كل شيء: القائمة البيضاء squid تفعل وظيفتها بالضبط، وعقدة LangChain هي عميل واحد يتجاوز الوكيل.

طريقتان لإصلاحه

أ. السماح باتصال عقدة LangChain المباشر (الأبسط). أضف قاعدة firewall/egress تسمح بـ n8n_container → \u003cdedicated_server\u003e:11434 مباشرة (وليس عبر squid)، وأضف المضيف إلى NO_PROXY بحيث لا يحاول أحد توكيله:
NO_PROXY=fbhbxxxxxx.ikexpress.com,localhost,127.0.0.1

ب. فرض undici عبر squid بدلاً من ذلك. احتفظ بالخروج مغلقًا للوكيل، لكن اجعل fetch عقدة LangChain يستخدمه. الإصدارات الحديثة من n8n توصل ProxyAgent عام undici من متغيرات بيئة الوكيل، الإصدارات الأقدم لا تفعل. لذا اضبط:
HTTP_PROXY=http://squid_proxy:3128
HTTPS_PROXY=http://squid_proxy:3128
وتأكد من أن بناء n8n الخاص بك فعلاً يطبقه على عقد LangChain (اختبر بعد إعادة التشغيل). إذا استمرت الفشل، فأنت على نسخة لا توكل undici، لذا عُد إلى الخيار أ.

طريقة سريعة للتأكد من الفرضية

اسمح مؤقتًا لحاوية n8n بالخروج المباشر إلى الخادم المخصص (تجاوز squid لهذا المضيف). إذا بدأت وكيل الذكاء الاصطناعي فورًا في العمل، فهو مؤكد عدم التوافق بين الوكيل/undici، واختر أ أو ب كمسارك الدائم.

شيئان أصغر للقضاء عليهما أثناء عملك هناك

  • عنوان URL قاعدة بيانات بيانات الاعتماد: يجب أن يكون http://\u003cdedicated_server\u003e:11434 مع المخطط والمنفذ، بدون شرطة مائلة زائدة. اختبار بيانات الاعتماد متساهل، لذا تحقق مرة أخرى من القيمة المحفوظة.
  • “think”: true: يعمل فقط على نموذج قادر على التفكير + n8n حديث. أطفئه أولاً أثناء تصحيح الأخطاء حتى لا يتمكن من إخفاء الخطأ الحقيقي، ثم أعد تفعيله.
3

أهلا بك @codeyourweb!

النقطة الأساسية هنا: عقدة AI Agent تستخدم عنوان URL الأساسي لبيانات اعتماد Ollama بطريقة مختلفة عن عقدة HTTP Request. خطأ fetch failed بدون رسالة خطأ إضافية عادة ما يشير إلى واحد من اثنين في إعدادك:

  1. وكيل Squid يعترض الاتصال - عقد الذكاء الاصطناعي في n8n تقوم بطلبات البث، وإذا تم تكوين وكيل squid الخاص بك للسماح فقط بنقاط نهاية محددة أو لا يدعم SSE/chunked transfer، فسيقطع الاتصال بصمت. حاول تجاوز الوكيل مؤقتًا بتعيين NO_PROXY=<dedicated_server_ip> في متغيرات بيئة حاوية n8n الخاصة بك واختبر عقدة AI Agent مرة أخرى.

  2. تنسيق عنوان URL للبيانات الاعتمادية - تأكد من أن عنوان URL الأساسي لبيانات اعتماد Ollama هو بالضبط http://<dedicated_server>:11434 بدون شرطة مائلة في النهاية. اختبار البيانات الاعتمادية أكثر تساهلاً من اتصال العقدة الفعلي.

من الجدير أيضًا التحقق منه: قم بتشغيل docker exec -it n8n_container curl http://<dedicated_server>:11434/api/tags من داخل حاوية n8n للتأكد من أن المسار المباشر يتم حله بشكل صحيح بدون المرور عبر squid.

4

مرحبا،

المشكلة مرتبطة فعلاً بالتوكيل (proxification). أؤكد أنها تعمل بإضافة خادمي المخصص إلى قائمة 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

هل تعتقد أنه يمكن عمل شيء ما للحفاظ على التوكيل؟

5

حسناً، هذا يؤكده. لكن هناك شيء يستحق الإشارة إليه: اقرأ سطري الحبار الخاصين بك بعناية، لأنهما يرويان قصة أكثر تحديداً من «عقدة الذكاء الاصطناعي تتجاوز الوكيل».

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

  • الـ 403 موجود فقط على CONNECT. يشحن Squid مع http_access deny CONNECT !SSL_ports، و 11434 ليس في SSL_ports، لذا أي عميل يحاول النفق (TLS / https_proxy) إلى هذا المنفذ يتم رفضه. هذا اختبار curl الخاص بك، وليس العقدة.
  • طلب عقدة الذكاء الاصطناعي عبارة عن GET بوكالة أمامية عادية وقد مر بالفعل عبر squid وأرجع 200 (HIER_DIRECT). لذا يمكن لعقدة LangChain أن تكون خلف squid. إنها ليست العميل الذي لا يمكن توكيله.

إذاً نعم، يمكنك الاحتفاظ بالوكيل. شيئان لإغلاقه:

  1. اجعل squid يتوقف عن إرسال 403 إلى 11434. أضف 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.) GETs العادية الخاصة بك تمر بالفعل، لذا هذا مهم فقط إذا حاولت العقدة النفق في يوم من الأيام، لكنه يزيل آخر مصدر لـ 403 صامت.

  1. تأكد من وصول استدعاء الاستدلال الفعلي إلى squid، وليس فقط /api/tags. /api/tags هو فحص قائمة بيانات الاعتماد والنموذج، وهو GET تافه. الشيء الذي كان فاشلاً هو استدعاء الدردشة المتدفقة. ذيل squid وقم بتشغيل الوكيل:

docker logs -f squid_container

ثم قم بتشغيل عقدة الذكاء الاصطناعي مرة واحدة

تريد أن ترى سطراً مثل POST http://…:11434/api/chat (أو /api/generate) يمر عبر TCP_MISS/200 HIER_DIRECT. إذا كان الأمر كذلك، فأنت انتهيت، الوكيل يبقى والوكيل يعمل. إذا ظهر /api/tags في squid لكن POST لم يظهر أبداً، فإن هذا الاستدعاء المحدد موجود على undici يتجاوز الوكيل، وأنت على بناء n8n لا ينطبق على وكيل ProxyAgent العام على fetch الخاص بـ LangChain. في هذه الحالة، خياراتك هي الترقية إلى إصدار n8n يسلك HTTP(S)_PROXY إلى undici، أو الاحتفاظ بالمضيف في NO_PROXY كحل بديل عملي (الذي أثبت أنه يعمل).

تنظيف سريع أثناء الاختبار: احفظ “think”: true بعيداً بحيث لا يمكن لخطأ في النموذج القادر على التفكير أن يتنكر كخطأ في النقل، وأعد التحقق من أن عنوان URL الأساسي المحفوظ للبيانات هو بالضبط http://‹host›:11434، بدون شرطة مائلة زائدة.

6

آسف على هذا الرد المتأخر، لم يكن لدي الوقت لحله من قبل. شكراً جزيلاً @Michael_Frostbutter، كنت محقاً!