إصلاح خطأ 503 فشل الاتصال بالخادم الخلفي على موقعك
يُعد خطأ 503 فشل جلب الواجهة الخلفية (Error 503 Backend Fetch Failed) خطأً من جانب الخادم يمكن أن يجعل موقع الويب غير قابل للاستخدام كليًا أو جزئيًا. يمكن أن يحدث هذا الخطأ عند محاولة الوصول إلى موقع ويب، أو تنزيل محتوى، أو استخدام معالج دفع، على سبيل المثال لا الحصر.
يشير هذا الخطأ إلى أن خادم موقع الويب لم يتمكن من التواصل بفعالية مع خدمات الواجهة الخلفية. وعادةً ما يتم تشغيله بسبب تحديثات الإضافات (plugins)، أو نظام تشغيل الخادم (server OS)، أو الامتدادات. ولأنه مشكلة من جانب الخادم، لا يمكن للعملاء سوى محاولة تحديث موقع الويب في متصفحاتهم.
استكشاف الأخطاء وإصلاحها الأساسي
- إعادة تحميل صفحة المتصفح: قم بحل خطأ 503 مؤقتًا عن طريق تحديث الصفحة عدة مرات.
- حالة الخادم: تحقق مما إذا كان الخادم المضيف معطلاً أو يخضع للصيانة.
- النسخ الاحتياطي: تأكد من وجود نسخة احتياطية للخادم والموقع وقاعدة البيانات لمنع فقدان البيانات أثناء استكشاف الأخطاء وإصلاحها.
- إعادة تحميل أو إعادة تشغيل الخدمات والخادم: حاول إعادة تحميل أو إعادة تشغيل الخدمات، مثل Varnish، وإذا استمر الخطأ، ففكر في إعادة تشغيل الخادم.
- التحديث: تحقق من أن جميع الخدمات والتطبيقات ونظام تشغيل الخادم (server OS) ذات الصلة محدثة.
3. التحقق من صحة الموقع والموارد
يمكن أن يتسبب نقص مساحة التخزين أو الموارد في موقع الويب في حدوث مشكلة فشل جلب الواجهة الخلفية بسبب عدم القدرة على تنفيذ العمليات الضرورية.
- انتقل إلى لوحة تحكم WordPress واختر الأدوات > صحة الموقع > المعلومات.
- قيّم ما إذا كان التخزين يقترب من حده الأقصى. إذا كان الأمر كذلك، فقد تحتاج إلى إضافة المزيد من مساحة التخزين أو حذف العناصر غير الضرورية. في بعض الحالات، قد يكون من الضروري ترقية خطتك.
- تأكد من أن موارد الخادم الأخرى ليست مثقلة وأن حل هذه المشكلة يزيل الخطأ.
4. التحقق من توفر الموارد
ستؤدي محاولة الوصول إلى مورد غير موجود على خادم الواجهة الخلفية إلى ظهور رسالة خطأ. قد يبلغ وكيلك العكسي عن هذا الخطأ كخطأ 503 (فشل جلب الواجهة الخلفية).
- تحقق من عنوان URL أو الرمز وحدد المورد الذي يحاول الوصول إليه.
- تحقق من توفر المورد المطلوب على الخادم. إذا كان غير موجود، قم بتحميل المورد إلى الموقع المناسب.
- إذا استمرت المشكلة، فتأكد من أن الإجراء الذي يتم تنفيذه لا يحاول تحميل الموقع بأكمله. على سبيل المثال:
.request ="GET HTTP/1.1"
راجع الأمر على النحو التالي:
.request ="GET /sitehealth.html HTTP/1.1"
5. تغيير إعدادات Cloudflare
يمكن أن تتسبب إعدادات Cloudflare غير المثلى في حدوث خطأ 503 عن طريق تقييد الوصول إلى موارد خادم الواجهة الخلفية. يمكن أن يؤدي تغيير هذه الإعدادات إلى تصحيح المشكلة.
- ادخل إلى لوحة تحكم Cloudflare وانتقل إلى الأمان > إجراء تغييرات على Elementor.
- انسخ الـ IP المعروض وانتقل إلى WAF > الأدوات.
- انقر على تحرير بجانب إدخال موقعك وأضف الـ IP إلى القائمة المسموح بها.
6. زيادة حد مهلة الخادم
إذا كان وقت استجابة الخادم الخلفي أطول مما تم تعيينه للوكيل العكسي للانتظار (مهلة)، فسيحدث خطأ في جلب البيانات من الخلفية. يمكن أن تؤدي زيادة حد مهلة الخادم إلى معالجة هذه المشكلة. قد يختلف هذا، ولكن في Varnish، يمكن القيام بذلك عن طريق:
- الانتقال إلى إعدادات Varnish. على سبيل المثال:
/etc/sysconfig/varnish
- تعديل ملف VCL Conf لزيادة وقت الانتظار إلى، على سبيل المثال، 300 ثانية (الافتراضي غالبًا 60 ثانية):
first_byte_timeout = 300s
- احفظ التغييرات وتحقق مما إذا كان الخطأ لا يزال موجودًا.
- إذا بدأ الخطأ بعد تغيير في إعدادات Varnish، فارجع إلى إعدادات أقدم وظيفية إذا كانت متاحة.
7. تعديل إعدادات فحص صحة الموقع
قد ينشأ خطأ الخادم الخلفي إذا كان ذاكرة التخزين المؤقت للوكيل العكسي، مثل Varnish، غير قادرة على الوصول إلى معلومات فحص صحة الخادم الخلفي أو تعتبرها معيبة. الحل هو إصلاح إعدادات فحص صحة الموقع:
- أزل السطر التالي من إعداداتك إذا كان موجودًا:
.url="/health_check.php"
- تحقق مما إذا تم حل المشكلة.
- إذا لم يتم ذلك، فاستخدم varnishlog لتحديد ما يتم وضع علامة عليه كغير صحي ومعالجته وفقًا لذلك.
sudo varnishlog -g request -q "VCL_call eq 'BACKEND_ERROR'"
8. إعادة إصدار PHP الخاص بالخادم إلى إصدار سابق
إذا كان تحديث إصدار PHP الأخير غير متوافق مع الواجهة الخلفية لموقعك الإلكتروني، فقد يؤدي ذلك إلى ظهور خطأ 503. يمكن أن يؤدي الرجوع إلى إصدار PHP سابق إلى حل المشكلة. على سبيل المثال، على Bluehost مع WordPress:
- انتقل إلى لوحة التحكم الخاصة بـ Bluehost وحدد علامة التبويب Advanced.
- ضمن cPanel، انتقل إلى MultiPHP Manager في قسم Software وحدد الموقع الإلكتروني المتأثر.
- قم بتغيير إصدار PHP مرة أخرى إلى الإصدار السابق وتحقق مما إذا تم حل الخطأ.
9. تعطيل الإضافات والأدوات والملحقات والقوالب
عندما تكون إضافة أو أداة أو ملحق أو قالب غير متوافق مع إعدادات الخادم، قد ينتج عن ذلك خطأ 503. قم بتخفيف الخطأ عن طريق تعطيلها وإعادة تمكينها واحدة تلو الأخرى لتحديد العنصر المسبب للمشكلة.
على سبيل المثال، لتعطيل GZip على Jira Service Desk، والذي عُرف بأنه يسبب خطأ 503:
- توجه إلى لوحة التحكم الخاصة بـ Jira وحدد Admin > General Settings > Use GZip Compression.
- عطّل ضغط GZip وتحقق مما إذا كان ذلك يحل الخطأ.
10. تعطيل وحدة CSP على Magento
توفر وحدة سياسات أمان المحتوى (CSP) الأمان لتطبيقات Magento. إذا كانت وحدة CSP غير متوافقة مع إعداداتك الحالية، فقد تتسبب في ظهور الخطأ 503.
قد يؤدي تعطيل وحدة CSP على Magento إلى حل المشكلة:
- شغل Terminal وقم بتشغيل الأوامر التالية تباعًا:
php bin/magento module:disable Magento_Csp php bin/magento c:f
- بعد التنفيذ، تحقق مما إذا كان الخطأ 503 قد تم تصحيحه.
11. تغيير رأس المضيف (Host Header) وعلامة الطفل (Child Tag) وتكوينات المنفذ (Port)
يمكن أن تنشأ أخطاء جلب الواجهة الخلفية (Backend fetch) أيضًا من رؤوس المضيف الكبيرة جدًا، أو علامات الطفل غير المهيأة بشكل صحيح، أو تكوينات المنفذ الخاطئة. قد يؤدي تعديل هذه الإعدادات إلى تصحيح الخطأ.
إضافة خاصية .host_header
- طبق خاصية .host_header لخادم الواجهة الخلفية لضمان توجيه الفحوصات إلى المضيف الصحيح.
- باشر تصحيح الأخطاء (debugging) لفحص تفاصيل رأس المضيف الواردة ضمن السجلات.
إزالة علامات الطفل (Child Tags) من Magento
- ادخل إلى هذا الملف:
MagentoConfigurableProductPluginModelProduct
- احذف علامة الطفل من الرأس وقيم ما إذا كان الخطأ قد تم حله.
إزالة المنافذ (Ports) من Docker Compose
- حدد موقع Docker Compose وانتقل إلى ملف Default.vcl.
- استبدل المنافذ بـ اسم الخدمة كما هو موضح أدناه:
client: image: ... ports: <-- إزالة - target: 80 published: 8080 mode: host
عدّل ملف Default.vcl وفقًا لذلك:
backend default { .host = "client"; .port = "80"; } - تحقق مما إذا كان هذا التعديل يحل المشكلة.
12. استخدام نهج منهجي
إذا فشلت جميع الخطوات السابقة، فيجب استخدام نهج منهجي لعزل سبب الخطأ 503.
فحص السجلات
- دقق في السجلات المرتبطة بالوكلاء العكسيين (reverse proxies)، أو PHP، أو خوادم الواجهة الخلفية (backend servers)، أو إعدادات الاستضافة بحثًا عن أي مخالفات قد تؤدي إلى الخطأ 503.
- إذا تم اكتشاف أي خلل، فقم بتصحيح المشكلة الأساسية للقضاء على الخطأ.
إجراء اختبار تعارض كامل
أجرِ اختبار تعارض كامل إذا كان إعدادك يسمح بذلك، لاكتشاف أي تعارضات محتملة. إذا نشأت أي تعارضات، فقم بحلها لإزالة خطأ جلب الواجهة الخلفية (backend fetch error).
الوصول المباشر إلى خادم الواجهة الخلفية
إذا كنت تستخدم وكيلًا عكسيًا (reverse proxy) مثل Varnish، فتجاوزه وحاول الوصول مباشرة إلى خادم الواجهة الخلفية (backend server). إذا نجحت هذه الطريقة، فمن المحتمل أن تكون المشكلة في إعداد الوكيل العكسي. ضع في اعتبارك الخطوات التالية إذا كان الوصول المباشر ناجحًا:
- قيّم طول وسوم الكاش المستخدمة بواسطة Magento—وهو أمر ذو أهمية خاصة للمتاجر التي تحتوي على العديد من المنتجات—حيث قد تتجاوز الحد الافتراضي المحدد في Varnish (عادةً 8192 بايت). للتصحيح، قم بتعديل http_resp_hdr_len (على سبيل المثال، إلى 70000 بايت) في إعدادات Varnish. وبالمثل، اضبط http_resp_size الخاص بـ Varnish.
- تأكد من أن ملف health_check.php موجود في الدليل الصحيح أو قم بتعديل إعدادات Varnish للإشارة إلى الموقع الدقيق. قد يكون الافتراضي هو /pub/health_check.php، ولكن بالنسبة لخوادم Nginx، قد يحتاج إلى التغيير إلى /health_check.php.
- بالنسبة لمواقع Magento، إذا كان ملف maintenance.flag موجودًا، فحاول حذفه أو إعادة تسميته ثم تحديث الموقع لمعرفة ما إذا تم حل الخطأ.
- تحقق من قواعد المنتجات داخل Magento من خلال تتبع عكسي (backtrace) لتحديد أي مخرجات غير صالحة قد تسبب الخطأ.
إذا كانت هذه الطرق غير فعالة، فقم بتجريد الموقع إلى عناصره الأساسية، مثل ملف فهرس (index file) يحتوي على بعض المحتوى النائب. أعد إدخال الميزات تدريجياً لتحديد أي منها يتسبب في ظهور الخطأ 503. إذا استمرت المشكلة، تواصل مع قنوات الدعم المناسبة للمساعدة، سواء كان دعم WordPress، أو دعم Magento، أو فريق خدمة عملاء مزود الاستضافة، مثل دعم Hostinger.
Comments are closed.