تشخيص أخطاء الموقع 404 و500 و502 و503
· PoolByte
عندما ترى خطأ على موقع ويب، يجب ألا يكون أول شيء هو تغيير جميع الإعدادات. يوفر رمز حالة HTTP معلومات أولية حول القسم الذي يجب التحقيق في المشكلة فيه. ولا يعني استخدام نفس تصميم صفحة الخطأ أن جميع المشكلات ناتجة عن نفس السبب. يجب تقييم عنوان URL والتطبيق وخادم الويب والخدمات بينهما بشكل منفصل.
بالإضافة إلى ذلك، قد يختلف الرمز المكتوب على الشاشة عن الرمز الذي تم إرجاعه بالفعل بواسطة الخادم. إذا كانت الإجابة التي تقول "لم يتم العثور على الصفحة" بإرجاع 200، فهذه استجابة HTTP ناجحة؛ المحتوى هو صفحة الخطأ. تحقق من رمز الحالة الفعلي باستخدام أدوات مطور المتصفح أو فحص HTTP المناسب.
تضييق نطاق المسألة أولا.
قم بتسجيل عنوان URL الدقيق الذي حدث فيه الخطأ والوقت وحالة المستخدم وآخر تغيير. هل المشكلة في صفحة واحدة أم في الموقع بأكمله؟ تسجيل الدخول أو الزوار المجهولين؟ هل هو نفسه على الهاتف المحمول وسطح المكتب؟ إذا كان هناك CDN أو وكيل عكسي، فحاول فصل الاستجابة التي ينتجها عن استجابة الخادم الأصلي.
على سبيل المثال، إذا قامت الصور فقط بإرجاع 404، فستأخذ مسارات الملفات الأولوية. إذا كانت جميع الصفحات الديناميكية تعطي 502 وتم فتح الملفات الثابتة، فيمكن التحقق من عمليات التطبيق أو اتصال الخادم الأصلي. هذه ليست تشخيصات نهائية، ولكنها أدلة تضيق نطاق السيطرة.
404: لم يتم العثور على المورد المطلوب
يشير 404 إلى أن الخادم لم يتمكن من العثور على المورد المطلوب. قد يتسبب عنوان URL غير الصحيح أو المحتوى المحذوف أو الملف المنقول أو اختلاف الحالة أو قاعدة إعادة التوجيه في حدوث ذلك. أولاً، تحقق مما إذا كان الملف أو المحتوى موجودًا بالفعل وأنه موجود في العنوان الصحيح.
إذا قمت بنقل منشور إلى عنوان جديد، فأعد توجيه عنوان URL القديم ذي المعنى إلى عنوان URL الجديد المقابل. إن إعادة توجيه جميع الصفحات التي لم يتم العثور عليها إلى الصفحة الرئيسية لن يضمن وصول الزائر إلى المحتوى الذي يبحث عنه. من الواضح أكثر الحفاظ على الاستجابة الصحيحة للخطأ للمحتوى الذي تمت إزالته بالفعل وليس له نظير.
إذا كانت عناوين النشر فقط لا تعمل في WordPress، فيمكن فحص تكوين إعادة توجيه الرابط الثابت والخادم. احفظ الإعدادات الحالية أولاً؛ لا تزيد من تعقيد الموقف بإضافة أجزاء .htaccess عشوائية. قارن أيضًا الأسماء ومسار الدليل للموارد.
500: حالة غير متوقعة في التطبيق أو الخادم
500 هو خطأ خادم شائع؛ لا يخبرك في حد ذاته بالخط الذي يمثل مشكلة. قد تكون هناك أسباب مثل مكون إضافي جديد، أو تكوين غير صحيح، أو عدم توافق PHP، أو فقدان التبعية أو حد الموارد. يعد الوقت وطلب المعلومات في سجل الأخطاء أكثر قيمة من التخمين.
حدد إصدار ونطاق التغيير الأخير. إذا أمكن، قم بإعادة إنتاج نفس الخطأ في بيئة التدريج . بدلاً من حذف المكونات الإضافية بشكل عشوائي، استخدم خطة عزل محكومة. لا تتداول في البث المباشر إلا إذا كنت ترى أن إيقاف تشغيل أحد المكونات لا يؤثر على سلوك الطلب أو الاشتراك أو المحتوى.
يمكن أن تكون خيارات تصحيح الأخطاء في WordPress مفيدة في بيئة الاختبار. بدلاً من إتاحة مخرجات الأخطاء التفصيلية للزائر، قم بفحصها في السجل ذي الوصول المحمي. لا ينبغي عرض مسار الملف ومعلومات الاتصال والبيانات الحساسة على الصفحة العامة. إذا كان هناك شك في تغيير PHP، استخدم تسلسل التحقق في دليل ترقية الإصدار.
502: تعذر على الخادم الوسيط تلقي استجابة صالحة
يشير 502 إلى أن الخادم الذي يعمل كبوابة أو وكيل غير قادر على تلقي استجابة صالحة من الخادم الأصلي. ربما توقفت عملية التطبيق، أو ربما كان مسار الاتصال خاطئًا، أو ربما لم يستجب الخادم الأصلي كما هو متوقع. لا تلوم المشكلة على ذاكرة التخزين المؤقت للمتصفح فقط.
يختلف ترتيب التحكم وفقًا لبنية الاتصال: عمليات CDN والوكيل العكسي وخادم الويب وعمليات PHP. حدد من السجلات أي مكون قام بإنشاء الكود. إذا تغير المنفذ أو الشهادة أو PHP-FPM أو إعداد الوكيل مؤخرًا، فقم بتضمين ذلك في المراجعة. إذا لم يكن لديك حق الوصول إلى الخادم، فاتصل بالموفر وأخبره بالوقت المحدد وعنوان URL.
قد تؤدي إعادة تشغيل الخدمة بشكل أعمى إلى تقليل الأعراض بشكل مؤقت، ولكنها قد تزيد من صعوبة العثور على السبب. قم أولاً بحفظ السجلات ذات الصلة وحالة الموارد. إذا كانت التهيئة مطلوبة، فحدد المواقع التي تؤثر عليها والشخص المسؤول.
503: الخدمة غير متاحة مؤقتًا
يشير 503 إلى أن الخدمة لا يمكنها حاليًا تقديم الطلب. الصيانة المجدولة أو التحميل الزائد من الأسباب المحتملة. التمييز بين وضع صيانة التطبيق وحد سعة الخادم. إذا تمت مقاطعة التحديث، فلا تقم بإزالة أي حالة صيانة متبقية دون التحقق من اكتمال العملية بالفعل.
في الحالات المناسبة، قد يوفر رأس Retry-After معلومات تتعلق بوقت إعادة المحاولة. ومع ذلك، فإن مجرد إضافة هذا العنوان إلى صفحة الخطأ لا يؤدي إلى إصلاح السعة. يساعد دليل موارد الاستضافة على تفسير حدود وحدة المعالجة المركزية والذاكرة والمعالجة.
قم بإدارة إعادة المحاولة بعناية على شاشة الدفع
حتى إذا أظهر طلب الدفع خطأً، فمن المحتمل أن يكون الموفر قد قبل المعاملة. قارن بين سجلات الطلب ومقدم الخدمة قبل توجيه المستخدم للدفع مرارًا وتكرارًا. عند حدوث الخطأ، يكون مرجع الطلب ومعلومات الحالة مهمة.
لا تشارك معلومات البطاقة أو كلمة المرور أو مفتاح الوصول في المستند التقني. قم بتزويد فريق الدعم بنص الخطأ الذي تم تنظيفه وعنوان URL والوقت وآخر تغيير تم إجراؤه. إذا أمكن، قم بتضمين معرف الطلب في استجابة الشبكة.
ما الذي يجب التحقق منه بعد التصحيح؟
- أعد محاولة استخدام عنوان URL المخالف وأي صفحات أخرى ذات صلة.
- تحقق من رمز HTTP الفعلي.
- تحقق من أن وظائف مثل النموذج والجلسة تعمل.
- انتبه للأخطاء الجديدة في السجل.
- امسح ذاكرة التخزين المؤقت إلى الحد المطلوب.
- اختتم بملاحظة مختصرة عن التغيير والنتيجة.
يعد رمز الحالة الصحيح مهمًا أيضًا لمحركات البحث. قد يؤدي تقديم محتوى الخطأ بشكل متكرر مع استجابة ناجحة أو استمرار أخطاء الخادم لفترات طويلة إلى إنشاء مشكلات في الزحف والفهرسة. يمكنك العثور على المزيد من عمليات التحقق هذه في دليل تحسين محركات البحث الفني .
الأسئلة المتداولة
هل يؤدي مسح ذاكرة التخزين المؤقت إلى إصلاح كل خطأ؟
لا، قد يكون مفيدًا في الحالات التي تظهر فيها الإجابة القديمة؛ ولا يقوم بإصلاح تطبيق معطل أو خادم أصل معطل.
هل يجب أن أقوم بترقية باقة الاستضافة الخاصة بي؟
قم أولاً بقياس ما إذا كان قد تم تجاوز حد الموارد بالفعل. إذا تم تأكيد مشكلة السعة، ففكر في خيارات استضافة الويب؛ يتطلب الرمز أو خطأ التوجيه حلاً مختلفًا.