أداة اختبار Webhook تبلغ عن "webhook_url is not valid (500)" رغم أن webhook الإنتاج يمكن الوصول إليه علنًا ويعمل مع curl

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

أنا أقوم بدورة أكاديمية n8n N8N102 القسم 2 (تقييم Webhook) ولا أستطيع اجتياز التحقق من webhook الأول.
مُختبِر Webhook الأكاديمي يُبلّغ:
“webhook_url غير صحيح. يرجى التأكد من أن اسم المضيف الخاص بك يتم حله وهو متاح للعموم بشكل عام. رمز الحالة: 500”
ومع ذلك، webhook الخاص بي متاح للعموم بشكل عام ويعمل بشكل صحيح عند اختباره يدويًا باستخدام curl.
لقد تحققت من ما يلي:
تم استخدام URL webhook الإنتاج (وليس عنوان URL الاختبار).
تم نشر سير العمل.
يعمل n8n على VPS عام خلف Nginx مع HTTPS.
DNS و SSL يعملان.
أعدت استخدام بيانات اعتماد مفتاح API أكاديمية n8n نفسه من القسم 1.
تم تعيين مصادقة Webhook إلى Header Auth.
يصل curl بنجاح إلى webhook.
عند تكوين webhook للرد الفوري، أتلقى:
{
“message”: “Workflow was started”
}
عند التكوين للرد باستخدام عقدة Respond to Webhook، أتلقى:
{
“code”: 0,
“message”: “No Respond to Webhook node found in the workflow”
}
مختبِر الأكاديمية لا يزال يبلّغ عن عنوان URL للـ webhook على أنه غير صحيح.
هل واجه أي شخص هذه المشكلة مع مختبِر Webhook الأكاديمي، أم أن هناك شيء معين يتوقعه المختبِر يختلف عن webhook عادي؟

ما رسالة الخطأ (إن وجدت)؟

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

شارك الناتج الذي تم إرجاعه بواسطة العقدة الأخيرة

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

  • إصدار n8n: 2.31.6
  • قاعدة البيانات (الافتراضي: SQLite): غير قابل للتطبيق
  • إعداد n8n EXECUTIONS_PROCESS (الافتراضي: own, main): الافتراضي
  • تشغيل n8n عبر (Docker, npm, n8n cloud, desktop app): Docker على Ubuntu VPS خلف Nginx
  • نظام التشغيل: Ubuntu 24.04 LTS

لقطة الشاشة الخاصة بـ curl هي الدليل الرئيسي هنا. هذا لا يبدو وكأنه DNS أو SSL أو Nginx بعد الآن، لأن الطلب يصل إلى n8n و n8n هو الذي يُرجع 500.

الخطأ المحدد يقول: “لم يتم العثور على عقدة Respond to Webhook في سير العمل”.

هذا عادة ما يعني أن عقدة Webhook مضبوطة على “الرد باستخدام عقدة Respond to Webhook”، لكن بالنسبة لهذا التنفيذ، لا يستطيع n8n الوصول إلى أي عقدة Respond to Webhook من مسار Webhook هذا.

إذا كان سير العمل الفعلي لديك يحتوي على عُقد أكثر من العقدة المشاركة، سأتحقق من أن عقدة Respond to Webhook متصلة بالفعل وتُصل دائماً لطلب POST هذا. للتحقق السريع، أضف عقدة Respond to Webhook مباشرة بعد Webhook وأرجع رد استجابة 200 بسيط، ثم شغّل curl مرة أخرى. بمجرد أن يُرجع curl 200 بدلاً من 500، يجب أن يتوقف مختبر Academy عن اعتبار URL غير صالح.

رسالة اسم المضيف الخاصة بالمختبِر مضللة هنا: رمز HTTP 500 والاستجابة No Respond to Webhook node found تثبت بالفعل أن الطلب مرّ بنجاح عبر DNS و TLS و Nginx وعقدة Webhook. إذا كانت مشكلة المصادقة عبر الرؤوس هي المشكلة، فستشاهد عادةً 401/403 بدلاً من هذا الخطأ 500 على مستوى سير العمل.

مع Using Respond to Webhook Node، يجب أن تكون عقدة Respond قابلة للوصول على كل مسار تنفيذ ممكن. عقدة Respond التي تكون غير متصلة أو معطلة أو موجودة فقط على فرع IF الآخر تعادل عدم وجود أي منها لهذا الطلب.

كنت سأعزلها بمسار واحد مؤقت:

Webhook (same POST + header auth) -> Respond to Webhook (fixed JSON, status 200)

أزل جميع فروع IF/database لهذا الاختبار وأرسل طلب curl يطابق طريقة المختبِر الأكاديمي والرؤوس والمتن. تأكد من أن التنفيذ يصل بوضوح إلى عقدة Respond وأن curl يستقبل 200. ثم استعد منطق التحقق وأنهِ كل فرع نجاح/خطأ برده قابل للوصول خاص به. إذا كان المختبِر الأكاديمي لا يزال يبلغ عن 500 بعد عودة المسار الأدنى إلى 200، فقارن طابع الوقت الخاص بالمختبِر مع سجل Nginx access لتأكيد أنه يضرب عنوان URL الإنتاج نفسه.