نحن نقوم بتشغيل n8n 2.26.4 محلياً على Elestio وغير قادرين على توصيل Claude.ai بمثيلنا عبر MCP. تم تفعيل MCP على مستوى المثيل وتم تكوين رمز OAuth/Access.
حاولنا كلاً من موصل شريك n8n الرسمي على Claude.ai وموصل مخصص يستخدم عنوان URL لخادم MCP المباشر (الصيغة: https://your-instance.vm.elestio.app/mcp-server/http). كلاهما فشل برسالة الخطأ نفسها من جانب Claude:
“فشل التفويض مع خادم MCP. يمكنك التحقق من بيانات اعتمادك والأذونات.”
ومن المثير للاهتمام أنه على جانب n8n، تعرض علامة التبويب Connected Clients إدخالات Claude جديدة تظهر في كل مرة نحاول فيها الاتصال، لذلك يستقبل n8n محاولة الاتصال. المشكلة هي أن مصافحة المصادقة لا تكتمل بنجاح من جانب Claude.
رموز المراجع من محاولات الفشل الثلاث:
- ofid_ccb9a1fd230c7285
- ofid_757ab36960e137e7
- ofid_a02cf908ec28723f
هل يمكن لأي شخص مساعدتنا في تحديد ما الذي يمنع اكتمال التفويض بنجاح؟
إعجاب واحد (1)
تلك الصفوف Connected Clients مفيدة: Claude يصل إلى n8n، وبالتالي الانقسام التالي هو اكتشاف URL مقابل تبادل التوكن. جرّب إعادة اتصال واحدة نظيفة باستخدام عنوان MCP المباشر، ثم افحص سجل n8n عن نفس ofid_...؛ إذا فشل أثناء تبادل التوكن، ألصق تلك السطر السجل الواحد مع إخفاء أسماء المضيفين/الأسرار ونوع بيانات اعتماد OAuth الذي استخدمته.
إعجاب واحد (1)
تحديث: لقد فحصنا السجلات بشكل أعمق وعثرنا على السبب الجذري.
كل محاولة اتصال تظهر:
ValidationError: An invalid 'request.ip' was detected
تليها مباشرة “Deleting OAuth client” و"OAuth client deleted successfully". يتم إنشاء جلسة OAuth ثم يتم فسخها فوراً لأن مقيد المعدل الخاص بـ n8n يرفض عنوان IP المشوه القادم من خادم nginx العكسي أمام نسختنا.
لقد عيّنا N8N_TRUST_PROXY=true وN8N_PROXY_HOPS=1 لكن المشكلة موجودة على مستوى nginx. يقوم Nginx بإعادة توجيه رؤوس X-Forwarded-For لكنه يفتقد إلى توجيهات real_ip_header وset_real_ip_from، لذلك يستقبل n8n عنوان IP مشوهاً ويحذف جلسة OAuth قبل أن يتمكن تبادل الرمز من الاكتمال.
لقد صعدنا الأمر إلى Elestio (موفر الاستضافة لدينا) لإضافة توجيهات real_ip الخاصة بـ nginx. هل يوجد أي شيء يمكننا فعله من جانب n8n لتجاوز أو تعطيل تحقق صحة عنوان IP الخاص بمقيد المعدل كحل مؤقت أثناء انتظارنا؟
شيء واحد يستحق التجربة أثناء انتظارك Elestio: اضبط N8N_PROXY_HOPS=0 مؤقتاً. يخبر هذا n8n أنه لا يعمل خلف أي وكيل، لذا يتوقف عن محاولة تحليل رؤوس X-Forwarded-For بالكامل ويستخدم عنوان IP للاتصال الخام بدلاً من ذلك - وهذا يحل مشكلة التحقق من صحة عنوان IP المشوهة التي تعطل عملية OAuth handshake. المقابل هو أن تحديد معدل التدفق سيتم تطبيقه على عنوان IP الوكيل بدلاً من عناوين IP لعملاء حقيقيين، لكن بالنسبة إلى خادم MCP فهذا بشكل عام مقبول. بمجرد أن يطبق Elestio توجيهات nginx real_ip_header و set_real_ip_from، قم بالتبديل مرة أخرى إلى N8N_PROXY_HOPS=1 بحيث يعمل تحديد معدل التدفق بشكل صحيح مرة أخرى.
إعجاب واحد (1)
Meesam، تعامل مع فكرة N8N_PROXY_HOPS=0 أعلاه كاختبار عزل مؤقت وليس كحل. فهو يجعل n8n يطبق حدود المعدل ضد عنوان IP للوسيط، لذا احرص على جعله قصير الأجل وعد للخلف بمجرد أن تعيّن Elestio سلسلة IP الحقيقية.
لا تعطّل المحدّد نفسه في n8n لهذا الغرض. الحل الدائم لا يزال في المنبع: يجب أن يمرر nginx سلسلة عناوين IP للعميل موثوقة صحيحة قبل أن يعمل مسار OAuth/حدود المعدل بشكل طبيعي.
إعجاب واحد (1)
تحديث: تم إحراز تقدم. تم إصلاح حلقة حذف OAuth. تُظهر السجلات الآن “تمت الموافقة على الموافقة” و"تم تدوير رمز التحديث وتصدير رمز وصول جديد" في كل محاولة، لذا يتم إكمال تدفق OAuth بنجاح على جانب n8n. ومع ذلك، لا يزال Claude.ai يعرض “فشلت المصادقة مع خادم MCP”. يحدث الفشل الآن بعد اكتمال OAuth، أثناء تهيئة جلسة MCP. هل لديك أي فكرة عما قد يسبب فشل جلسة MCP بعد مصافحة OAuth ناجحة؟
يا Meesam، إذا كان n8n يظهر الآن موافقة الموافقة وتدوير الرمز، توقف عن البحث في مسار الوكيل/IP لهذا الجزء. الفحص التالي هو ما إذا كان Claude يصل إلى نقطة نهاية MCP بعد OAuth: في نفس المحاولة، هل تظهر سجلات n8n طلب إلى /mcp-server/http بعد سطر الرمز، أم أنها تصبح صامتة؟
إذا أصبحت صامتة، فمن المرجح أن الموصل يفشل قبل أن يصل تهيئة الجلسة إلى n8n. إذا وصل طلب، الصق سطر الخطأ الأول في جلسة MCP مع تحرير أسماء المضيفين/الرموز؛ رمز الحالة هناك مهم أكثر من سطور OAuth الآن.
تحققت من السجلات فوراً بعد محاولة الاتصال. بعد “Consent approved” وتدوير الرمز، تصبح السجلات صامتة تماماً. لا توجد طلبات إلى /mcp-server/http على الإطلاق. إذاً Claude ينهي OAuth بنجاح لكن لا يصل أبداً إلى نقطة نهاية تهيئة جلسة MCP. ما الذي قد يجعل Claude.ai يتوقف قبل الوصول إلى /mcp-server/http بعد تبديل رمز ناجح؟
هذا يضيّق احتمالات كثيرة: إذا صمت n8n بعد تدوير التوكن، فالخطوة الفاشلة على الأرجح لم تعد تتعلق بـ n8n الذي يقبل نتيجة OAuth. Claude يتجاوز ذلك، ثم لا يبدأ طلب جلسة MCP.
الدليل التالي هو عنوان MCP URL من جانب العميل الذي حفظه Claude. هل هو بالضبط عنوان https://.../mcp-server/http العام، بدون شرطة مائلة زائدة أو إعادة كتابة المسار من Elestio؟ إذا كان هذا العنوان دقيقًا ولا يزال n8n لا يرى شيئًا بعد تدوير التوكن، فهذا على الأرجح من جانب عميل Claude البعيد للـ MCP وليس من إعدادات سير عمل n8n.
حاولت استخدام مفتاح API بدمجه في عنوان URL كمعامل استعلام. لكنني ما زلت أتلقى رسالة الخطأ “فشل الترخيص مع خادم MCP” من جانب Claude.
طريقة معامل الاستعلام لن تعمل - عميل MCP الخاص بـ Claude.ai يرسل الرمز كـ Authorization: Bearer <key> في رأس الطلب وليس كمعامل URL. المشكلة على الأرجح أن nginx الخاص بـ Elestio يزيل رأس Authorization قبل وصوله إلى n8n.
في إعدادات nginx الخاصة بـ Elestio، تأكد من وجود هذا في كتلة الموقع التي تتعامل مع MCP:
proxy_set_header Authorization $http_authorization;
بدون هذا، يمرر nginx ملفات تعريف الارتباط والرؤوس المخصصة لكن يسقط رأس Authorization بشكل افتراضي، لذلك خادم MCP الخاص بـ n8n لا يرى الرمز أبداً ويرفض الاتصال. بمجرد وجود رأس passthrough في مكانه، استخدم مفتاح API الخاص بـ n8n مباشرة في موصل Claude - لا حاجة لتضمين URL.
إعجاب واحد (1)
تحديث: تم اختبار نقطة نهاية MCP مباشرة باستخدام curl. تعلن نقطة النهاية عن مصادقة Bearer عبر WWW-Authenticate: Bearer realm="n8n MCP Server" لكنها تُرجع "Missing Bearer prefix" حتى عند إرسال رأس Authorization: Bearer <token> صحيح. يصل الرمز إلى n8n (تم التأكد من أن nginx يمرر رؤوس التفويض). يُرجع كل من رمز وصول MCP ومفتاح API الخاص بـ n8n HTTP 401. هل هناك تنسيق رمز أو نقطة نهاية محددة يتوقعها خادم MCP للمصادقة المباشرة عبر Bearer في الإصدار 2.26.4؟
تم الحل - إليك ما أصلحه فعلاً لأي شخص على Elestio:
السبب الجذري كان أن إعدادات Elestio nginx تفتقد توجيهات وكيل معينة متعلقة بـ MCP. على الرغم من أن nginx كان يمرر رؤوس Authorization للمسارات الأخرى، فإن كتلة الموقع التي تتعامل مع نقطة نهاية n8n MCP (/mcp-server/http) لم تكن مكوّنة بشكل صحيح لتمرير الرؤوس والتعامل مع تهيئة جلسة MCP.
كان الحل هو قيام Elestio بتحديث إعدادات nginx لخدمة n8n باستخدام توجيهات الوكيل الصحيحة لنقطة نهاية MCP. لم نحصل على السطور الدقيقة التي غيروها لكن الأعراض كانت:
- اكتمال OAuth بنجاح (الموافقة على الموافقة، الرموز الصادرة في سجلات n8n)
- لم تصل Claude مطلقاً إلى
/mcp-server/http بعد تبادل الرمز، السجلات أصبحت صامتة
- استدعاء curl مباشر إلى
/mcp-server/http برمز Bearer أرجع 401 برسالة خطأ متناقضة “Missing Bearer prefix” حتى عندما كان البادئة Bearer موجودة
- بعد أن حدثت Elestio إعدادات nginx MCP، عملت الاتصال فوراً
أشياء أخرى أصلحناها على طول الطريق التي لم تكن السبب الجذري لكنها كانت مشاكل حقيقية:
- كان n8n على الإصدار 1.121.3، تم الترقية إلى 2.26.4 (مطلوب للحصول على دعم MCP مستقر)
- أضفنا
N8N_TRUST_PROXY: "true" إلى docker-compose.yml (ممارسة جيدة خلف وكيل عكسي)
- كان
N8N_PROXY_HOPS=1 مضبوطاً بالفعل بشكل صحيح، لا تغير هذا
إذا كنت على Elestio وتواجه الجدار نفسه، افتح تذكرة دعم واطلب منهم تحديث إعدادات nginx MCP لخدمة n8n الخاصة بك. أصلحوها بسرعة عندما أعطيناهم الخطأ المحدد.
إعجاب واحد (1)
