انتقل للمحتوى
سمسم لاب حلول ووردبريس من تجربة حقيقية
البريد والجدولة

فشل طلب Loopback في ووردبريس؟ تجربة تربطه بـ WP-Cron

كتب بواسطة محمد سعدي سلامة آخر تحديث: 5 دقائق قراءة

فحص صحة الموقع بحكيلك ان موقعك لا يستطيع اكمال طلب loopback، وبنفس الوقت المقالات المجدولة والمهام الخلفية ما بتشتغل؟ loopback يعني ان خادم ووردبريس يطلب عنوان موقعه بنفسه. ممكن الصفحة تفتح عندك بشكل طبيعي، لكن الطلب الداخلي ينحظر من جدار حماية او Basic Auth او DNS او SSL.

عملنا تجربة مضبوطة: إضافة مؤقتة اعترضت طلبات HTTP التي يرسلها ووردبريس إلى نطاقه، وجدولنا حدثا يزيد عدادا مرة واحدة. شغلنا فحص loopback الرسمي وطلب wp-cron، ثم رفعنا المنع واعدنا القياس وشغلنا الحدث.

المشكلة ظهرت حديثا في دعم ووردبريس مع 403 وتعطل الاحداث، وظهرت كمان في نقاش ريديت حديث عن REST وloopback 403. الارقام والصور التالية من مختبرنا.

النتيجة باختصار

  • مع قاعدة المنع صار فحص صحة الموقع critical.
  • طلب wp-cron رجع خطا smsm_loopback_blocked.
  • الحدث المستحق بقي مجدولا وعدد تشغيله صفر.
  • بعد رفع المنع صار فحص loopback good وطلب wp-cron رجع 200.
  • شغل Cron الحدث مرة واحدة، ثم اختفى الموعد من القائمة.

قبل الاصلاح: الموقع يفتح لكن ما يقدر يطلب نفسه

قاعدة المختبر ما منعت الزائر من فتح الصفحة. هي عملت داخل WordPress HTTP API فقط، ورجعت WP_Error لكل طلب داخلي إلى نفس المضيف. استدعينا WP_Site_Health::get_test_loopback_requests() وسجلنا النتيجة.

تقرير فحص صحة الموقع يظهر حالة critical وحظر طلب wp-cron وبقاء الحدث من غير تنفيذ
فحص صحة الموقع صار critical، وطلب wp-cron انحظر، والحدث بقي من غير تنفيذ.

هذا يشرح ليش اختبار الموقع من جوالك او جهازك مش كافي. مسار الخادم إلى نفسه ممكن يمر عبر Cloudflare او موازن حمل او شهادة مختلفة عن المسار الذي تستخدمه انت.

بعد رفع المنع

غيرنا خيار المختبر من محظور إلى مسموح من غير حذف الحدث. اعدنا فحص صحة الموقع فرجع Your site can perform loopback requests، وطلب POST إلى wp-cron رجع HTTP 200.

تقرير تجربة يظهر تحول فحص loopback إلى good ونجاح طلب wp-cron برمز 200 بعد رفع قاعدة المنع
نفس العنوان ونفس نسخة ووردبريس بعد رفع القاعدة: loopback جيد وwp-cron متاح.

رمز 200 يثبت الوصول، لكنه لا يثبت وحده ان كل مهمة اكتملت. لذلك شغلنا Cron من الخادم وسجلنا عداد callback والموعد.

تنفيذ الحدث الفعلي

كان الحدث مستحقا قبل الاختبار. بعد اصلاح المسار شغل ووردبريس callback مرة واحدة، تغير العداد من صفر إلى 1، ولم يعد wp_next_scheduled() يجد موعدا له.

تقرير تجربة يظهر تنفيذ الحدث مرة واحدة واختفاء موعده وبقاء قاعدة المنع معطلة
تنفيذ واحد وصفر حدث معلق بعده. هذا هو دليل اكتمال المهمة، مش رمز 200 فقط.

فيديو توثيق التجربة الفعلية

هذا تسجيل شاشة صامت ومتواصل للاختبار وهو يحدث داخل بيئة محلية معزولة. تظهر الخطوات والنتائج الفعلية لحظة التنفيذ، من غير تركيب صور ثابتة.

تسجيل شاشة صامت ومتواصل لتجربة فعلية داخل بيئة محلية معزولة. يعرض الحالة السليمة، تنفيذ المسبب، ظهور النتيجة، ثم الاصلاح واعادة الفحص. لا يستخدم صورا مركبة.

اسباب loopback الشائعة

  • جدار حماية يرجع 403 لعنوان IP الخاص بالخادم.
  • Basic Auth على staging من غير تمرير بيانات الدخول للطلب الداخلي.
  • النطاق يرجع من داخل الخادم إلى عنوان خاطئ او لا يحل DNS.
  • شهادة SSL غير موثوقة داخل نظام الخادم.
  • تحويلات HTTPS او www تعمل حلقة.
  • منع wp-cron.php او admin-ajax.php بقاعدة حماية واسعة.
  • اتصال داخلي بطيء ينتهي بـ timeout.

تشخيص مرتب

  1. افتح ادوات ثم صحة الموقع وسجل نص loopback الكامل والرمز.
  2. من الخادم نفسه اطلب نطاق الموقع، مش localhost فقط.
  3. افحص DNS وSSL والتحويلات وHTTP status.
  4. راجع سجل WAF في نفس ثانية الفحص وابحث عن IP الخادم.
  5. اختبر wp-cron.php وadmin-ajax.php كل واحد لحاله.
  6. اذا في Basic Auth مرر بياناته للطلب الداخلي او استثن مسار الفحص على staging.
  7. بعد الاصلاح نفذ حدثا محدودا وتأكد من اثره، مش من 200 فقط.

هل نوقف التحقق من SSL؟

استخدام sslverify=false يخفي مشكلة الثقة ويضعف الحماية، وما يصلح DNS او 403. ثبت سلسلة الشهادة الصحيحة وحديث حزمة CA في الخادم. استخدم تعطيل التحقق فقط في مختبر مغلق لتأكيد الفرضية ثم ارجعه.

Cloudflare وWAF

اذا الطلب من المتصفح 200 ومن الخادم 403، قارن IP وUser-Agent والرؤوس. اعمل استثناء ضيقا لمسار wp-cron او IP الخادم بعد مراجعة القاعدة. لا تطفئ الحماية لكل الموقع.

هل Cron النظام يلغي الحاجة إلى loopback؟

تشغيل wp-cron.php مباشرة من Cron النظام يقلل اعتماد النشر على loopback والزيارات، لكنه ما يصلح ميزات اخرى تستخدم طلبات ذاتية مثل فحص صحة القوالب والإضافات. افصل المشكلتين: ثبت Cron نظام للموثوقية، واصلح loopback اذا تحتاجه بقية الادوات.

فرق loopback عن REST

الاثنان قد يفشلان معا بسبب DNS او WAF، لكنهما مش نفس الاختبار. REST هو API، اما loopback فهو اتجاه الاتصال من الخادم إلى موقعه. متصفحك ممكن يفتح REST بينما الخادم نفسه محظور.

ماذا ترسل للاستضافة؟

ارسل الوقت الدقيق، النطاق والمسار، IP الخادم، رمز HTTP او كود cURL، ونتيجة الطلب من داخل الخادم. عبارة صحة الموقع فيها خطا ما بتكفي لتحديد قاعدة ModSecurity او مشكلة DNS.

تنظيف المختبر

بعد القياس حذفنا الحدث والعداد وخيار المنع، وعطلنا إضافة المختبر وحذفنا ملفها. ما تركنا استثناء حماية او Cron اضافيا على الموقع.

الخلاصة

قاعدة واحدة جعلت فحص loopback critical ومنعت wp-cron وتركت الحدث معلقا رغم ان الموقع نفسه يفتح. بعد رفعها عاد الفحص good ورجع الطلب 200، ثم نفذ الحدث مرة واحدة واختفى. التشخيص الصحيح يحتاج اختبارا من الخادم إلى نطاقه ثم اثبات اثر المهمة.

وسوم المقال:
روابط داخلية مفيدة