N8N Webhook مش بيرد؟ الحل خطوة بخطوة

مقدمة

لو بتستخدم n8n عشان تعمل أتمتة لمهامك، أكيد الـ Webhook جزء أساسي من شغلك. لكن ساعات كتير بنلاقي N8N Webhook مش بيرد، وممكن ده يوقّف شغلنا كله. يعني إيه ويب هوك (Webhook)؟ هو ببساطة طريقة تخلي تطبيق معين يبعت بيانات (إشعارات) لتطبيق تاني أول ما يحصل حدث معين، وده بيتم عن طريق URL مخصص.

المشكلة دي ممكن تكون محيرة، خصوصًا إن مفيش حل واحد ينفع لكل الحالات. عشان كده، في المقالة دي هتمشي معانا خطوة بخطوة عشان نعرف إيه سبب إن الـ Webhook بتاعك مش شغال وإزاي نصلحه، سواء كنت بتستخدم n8n Cloud أو عامل له Self-hosting.

إيه الفرق بين Test URL و Production URL في n8n؟

الـ Test URL والـ Production URL هما لينكَيْن مختلفين بيستخدمهم الويب هوك في n8n، وكل واحد ليه استخدام معين. الـ Test URL (أو Test Webhook URL) بتلاقيه أول ما تفتح الـ Webhook node في الـ workflow بتاعك وبتدوس على زرار “Execute Workflow” في الـ Builder.

اللينك ده مخصص للاختبارات، يعني لما تبعت عليه بيانات، الـ workflow هيشتغل مرة واحدة بس وبعدين هيقف ويستنى منك تدخل بيانات تانية يدوي أو تدوس “Execute Workflow” تاني. ده بيساعدك تشوف كل خطوة في الـ workflow وهي شغالة وتعدل فيها براحتك. لكن الـ Production URL (أو Production Webhook URL) هو اللينك الثابت اللي المفروض تستخدمه في تطبيقاتك الخارجية عشان تبعت البيانات باستمرار. اللينك ده بيشتغل بشكل تلقائي ومستمر طول ما الـ workflow “شغال” (Active).

ليه الويب هوك بيشتغل في Test ومش في Production؟

المشكلة دي بتحصل كتير وهي من أشهر مشاكل n8n. السبب الرئيسي إن الويب هوك بيشتغل في Test ومبيشتغلش في Production هو إن الـ workflow بتاعك مش “Active”. الـ Test URL بيشتغل حتى لو الـ workflow مش Active عشان ده مخصص للاختبار المباشر من الـ UI. لكن عشان الـ Production URL يشتغل صح ويستقبل البيانات باستمرار، لازم تتأكد إنك عامل “Activate” للـ workflow بتاعك.

عشان تعمل كده، هتروح على الشاشة الرئيسية للـ workflow في n8n، وهتلاقي زرار “Active” في الزاوية العلوية على اليمين. لازم الزرار ده يكون أزرق ومعناه إن الـ workflow شغال. دي خطوة أساسية كتير من المبتدئين بينسوها، ولما تتصلح، غالبًا المشكلة بتتحل على طول. لو المشكلة لسه موجودة، يبقى ممكن تكون المشكلة أكبر شوية.

إزاي تختبر الويب هوك بنفسك باستخدام أداة زي Postman؟

عشان تتأكد إن المشكلة مش من الخدمة اللي بتبعت البيانات، أفضل طريقة هي إنك تختبر الـ Webhook بشكل مستقل. ممكن تستخدم أدوات زي Postman أو Insomnia، أو حتى أمر cURL في الـ Terminal. ده بيساعدك تعرف إذا كان الـ Webhook بتاعك بيستقبل البيانات من الأساس ولا لأ، بغض النظر عن المصدر الأصلي للبيانات.

لو هتستخدم Postman: اختار نوع الـ Request (غالبًا POST أو GET على حسب إعدادات الـ Webhook node في n8n)، وحط الـ Production Webhook URL في خانة الـ URL، وبعدين ضيف الـ Body لو الـ request بتاعك محتاج بيانات. دوس “Send” وشوف الـ Response. لو الـ Webhook بتاعك صح هيجيب لك رد 200 OK أو أي رد تاني أنت محدده. لو هتستخدم cURL، ممكن تبعت request بالشكل ده (مع تعديل الـ URL والـ Body على حسب حالتك):

curl -X POST -H "Content-Type: application/json" -d '{"key": "value"}' https://your-n8n-webhook-url.com

الخطوة دي هتوضح لك إذا كان الـ n8n بيستقبل الـ request من الأساس ولا في حاجة بتمنع وصول الـ request لـ n8n.

حل مشاكل الويب هوك في حالة الـ Self-hosting

لو عامل Self-hosting لـ n8n، فيه كام نقطة لازم تركز عليها لأنها بتكون السبب في معظم المشاكل:

• متغير `WEBHOOK_URL` في ملف .env: لازم تتأكد إنك مضبط متغير البيئة `WEBHOOK_URL` صح في ملف `.env` بتاع n8n. اللينك ده هو اللي n8n بيستخدمه عشان يولد الـ Production Webhook URLs. لو مش مظبوط، الـ Webhooks مش هتشتغل. حسب n8n docs، لازم تحط الـ URL اللي n8n يقدر يوصل له من الإنترنت، زي `https://your-n8n-domain.com/`.
• مشاكل الـ Firewall: ممكن الـ Firewall على السيرفر بتاعك يكون مانع الوصول للبورت اللي n8n شغال عليه (البورت الافتراضي هو 5678). لازم تتأكد إن البورت ده مفتوح للاتصالات الواردة.
• مشاكل الـ Reverse Proxy (زي Nginx أو Cloudflare): لو بتستخدم Reverse Proxy، لازم تكون الإعدادات بتاعته صحيحة عشان يوجه الـ Traffic لـ n8n. مع Cloudflare، فيه نقطتين مهمين:
  • Cloudflare WAF: ساعات الـ Web Application Firewall بتاع Cloudflare بيحجب الـ requests اللي جاية للـ Webhook لو شايفها مشكوك فيها. ممكن تحتاج تعمل Rule تسمح بالـ requests دي.
  • إعدادات الـ DNS (Orange Cloud vs. Grey Cloud): لو عايز Cloudflare يعمل proxy للـ requests، لازم تكون علامة الـ Proxy Status في إعدادات الـ DNS عندك لونها “برتقالي” (Orange Cloud). لو “رمادي” (Grey Cloud)، يبقى Cloudflare مش بيعمل proxy والـ requests هتروح مباشرة للسيرفر بتاعك، وممكن ده ميكونش الإعداد اللي أنت عايزه أو إن الـ Firewall بتاعك هيمنعها.

إزاي تقرا الـ Execution Logs عشان تعرف سبب الخطأ؟

الـ Execution Logs هي سجل لكل مرة الـ workflow بتاعك بيشتغل فيها، وهي كنز لمعرفة سبب المشكلة لما الـ Webhook N8N Webhook مش بيرد. كل ما Webhook يستقبل بيانات أو يحاول يستقبلها، n8n بيسجل ده في الـ logs. عشان تشوف الـ logs: روح على الـ workflow اللي فيه المشكلة، وبعدين دوس على “Executions” في القائمة اللي على الشمال.

هنا هتلاقي كل محاولات تشغيل الـ workflow، سواء نجحت أو فشلت. لو الـ Webhook استقبل بيانات لكن الـ workflow فشل بعد كده، هتشوف الرسالة دي. ولو الـ Webhook مظهرش في الـ logs أساسًا، ده معناه إن البيانات موصلتش لـ n8n من الأول، فالمشكلة بتكون في نقطة قبل n8n (زي Firewall أو Reverse Proxy أو السيرفر اللي بيبعت البيانات). ابحث عن أي رسائل خطأ حمراء أو تحذيرات عشان تفهم إيه اللي حصل بالضبط.

يعني إيه Timeout وإزاي تخلي الـ Workflow يرد صح؟

الـ Timeout هو وقت محدد لو الـ workflow بتاعك محققش مهمته وخلص في الفترة دي، الـ request اللي بعت الـ Webhook بيتقفل وبيبقى فيه خطأ. في n8n Cloud، الـ Timeout عادةً بيكون 100 ثانية. يعني لو الـ workflow بتاعك بياخد وقت أطول من 100 ثانية عشان يخلص (مثلًا بيعمل عمليات معقدة أو بيتصل بـ APIs بطيئة)، ممكن الـ Webhook يفشل بسبب الـ Timeout.

عشان تخلي الـ Workflow يرد صح على الـ Webhook، خصوصًا لو العمليات طويلة، استخدم الـ “Respond to Webhook” node. الـ node ده بيسمح لك تبعت رد فوري للخدمة اللي بعتت الـ Webhook، وبعدين الـ workflow ممكن يكمل شغله في الخلفية. ببساطة، بتحط الـ “Respond to Webhook” node بدري في الـ workflow بتاعك بعد ما تستقبل البيانات الأساسية، وقبل أي عمليات بتاخد وقت طويل. كده الخدمة اللي بعتت الـ Webhook هتستقبل رد سريع (200 OK مثلًا)، وتضمن إن الـ Webhook مش هيفشل بسبب الـ Timeout. لو عايز تتعمق أكتر في أتمتة المهام والذكاء الاصطناعي، شوف الكورسات بتاعتنا.

الأسئلة الشائعة

ملخص المقالة

عشان نلخص، حل مشكلة N8N Webhook مش بيرد بيتطلب منك تمشي على خطوات تشخيص منظمة. ابدأ دائمًا بالتأكد إن الـ workflow Active، وافهم الفرق بين Test و Production URL. بعد كده، اختبر الـ Webhook بشكل مستقل، ولو عامل Self-hosting، راجع إعدادات `WEBHOOK_URL` والـ Firewall والـ Reverse Proxy (خاصة Cloudflare). متنساش كمان تبص على الـ Execution Logs وتفهم فكرة الـ Timeout وإزاي تستخدم “Respond to Webhook” node. باتباع الخطوات دي، هتقدر تحدد المشكلة وتحلها بسرعة، وتضمن إن الأتمتة بتاعتك شغالة زي الفل.