باختصار: الموقع المتوقف لا يحتاج أولاً إلى «إصلاح»، بل إلى تشخيص سريع يمنع تفاقم المشكلة. هذه قائمة فحص مرتبة زمنياً: تحقق من التوقف، اقرأ رمز الاستجابة، افحص الموارد، اعزل آخر تغيير، ثم اختر بين الإصلاح والاستعادة والنقل. عشر دقائق قد توفّر عليك يوماً كاملاً من التخمين.

قبل البدء: ثلاث قواعد تحمي موقعك

قبل أي أمر أو نقرة، التزم بهذه القواعد. معظم الكوارث التي نراها لا يسببها العطل الأول، بل رد الفعل المتسرع عليه.

  1. لا تحذف شيئاً بعد. لا تحذف إضافات، ولا تعِد تثبيت ووردبريس، ولا تفرغ قاعدة البيانات. الحذف يمحو الأدلة ويجعل الاستعادة أصعب.
  2. سجّل آخر تغيير حدث. تحديث إضافة أو قالب، نشر كود، تجديد نطاق، تغيير DNS، نقل استضافة، أو حتى تعديل صلاحيات ملفات. اكتب الوقت والتغيير قبل أن تنسى.
  3. خذ نسخة من الحالة الحالية إن أمكن. نسخة من الملفات وقاعدة البيانات قبل أي تعديل، حتى لو كان الموقع يعمل جزئياً. هذه النسخة هي نقطة الرجوع، وليست بديلاً عن التشخيص.
تحذير

لا تستعد نسخة احتياطية قديمة مباشرة. إن كان السبب اختراقاً أو خطأ برمجياً مستمراً، فاستعادة نسخة قديمة قد تعيد المشكلة نفسها وتفقدك بيانات جديدة.

الدقيقة 1–2: هل الموقع متوقف فعلاً؟

ابدأ من خارج شبكتك. افتح الموقع من هاتف على بيانات الجوال، أو استخدم أداة فحص خارجية. أحياناً يكون الموقع يعمل، والمشكلة في كاش متصفحك أو شبكتك أو Cloudflare.

افحص رمز الاستجابة من الطرفية:

bash
curl -sS -o /dev/null -w "HTTP %{http_code} | %{time_total}s\n" https://your-site.com
  • 200: الموقع يستجيب. المشكلة قد تكون في كاش المتصفح أو صفحة معينة.
  • 301/302: إعادة توجيه. تحقق أين تنتهي، فقد تكون حلقة لا نهائية.
  • 403: مطلوب منع وصول أو قاعدة جدار حماية.
  • 404: المسار غير موجود، وليس توقفاً عاماً.
  • 500/502/503/504: الخادم أو التطبيق لا يستجيب بشكل صحيح.
  • 522/524: Cloudflare لا يصل إلى خادمك.
  • 525/526: مشكلة في شهادة SSL بين Cloudflare وخادمك.

ثم تحقق من النطاق والشهادة:

bash
dig +short your-site.com
curl -vI https://your-site.com 2>&1 | grep -E "subject:|expire date:|SSL certificate"

إن كان النطاق لا يفتح عند أحد، أو الشهادة منتهية، فأنت أمام مسار مختلف عن خطأ التطبيق. أداة فحص السرعة والاستضافة تعطيك صورة أولية سريعة عن الاستجابة وشهادة SSL قبل أن تبدأ.

الدقيقة 3–4: اقرأ رمز الاستجابة قبل أي إصلاح

رمز الاستجابة هو أول دليل موضوعي. لا تبدأ بتعطيل الإضافات العشوائي؛ اقرأ الرمز ثم اذهب إلى السجل المناسب.

الرمز أين تبحث أولاً السبب الشائع
500 سجلات PHP وسجل ووردبريس خطأ في قالب أو إضافة أو كود PHP
502 حالة PHP-FPM وسجل Nginx خدمة PHP متوقفة أو مجمّعها ممتلئ
503 ملف الصيانة والموارد صيانة مفعّلة أو نفاد موارد
504 زمن استجابة PHP وMySQL استعلام بطيء أو خادم مشغول
522/524 اتصال Cloudflare بالخادم جدار حماية أو خادم متوقف
525/526 شهادة SSL على الخادم شهادة منتهية أو غير مطابقة

لكل رمز مسار تشخيص مختلف. إن كان الرمز 500 أو 502، فـدليل الفرق بين 500 و502 يشرح مصدر كل واحد وخطة إصلاحه.

اقرأ آخر الأخطاء:

bash
tail -n 50 /var/log/nginx/error.log
tail -n 50 /path/to/wp-content/debug.log

في ووردبريس، لا تفعّل WP_DEBUG على موقع الإنتاج أمام الزوار. استخدم تسجيلاً إلى ملف عبر WP_DEBUG_LOG وWP_DEBUG_DISPLAY مضبوطاً على false، ثم اقرأ الملف. الخطأ الأول في السجل غالباً هو السبب، وما بعده مجرد نتائج متسلسلة.

الدقيقة 5–6: افحص الموارد والمساحة

كثير من حالات «الموقع لا يعمل» سببها بسيط: القرص ممتلئ، أو الذاكرة انتهت، أو عدد الملفات (inodes) وصل حده، أو خدمة MySQL توقفت.

bash
df -h
df -i
free -m
# استبدل 8.3 بإصدار PHP المثبت لديك
systemctl status nginx php8.3-fpm mysql
top -b -n1 | head -15
  • القرص ممتلئ: ابحث عن السجلات الضخمة والنسخ القديمة والملفات المؤقتة. لا تحذف مجلدات النظام.
  • inodes ممتلئة: عدد الملفات كبير حتى لو كانت المساحة متاحة. ابحث عن مجلدات جلسات أو كاش متضخمة.
  • الذاكرة منتهية: خدمة MySQL أو PHP-FPM تُقتل بسبب نفاد الذاكرة. راجع dmesg بحثاً عن Out of memory.
  • PHP-FPM لا يعمل: أعد تشغيل الخدمة بعد قراءة سبب التوقف، لا قبلها.

إن كان الخادم يعمل لكنه يتوقف كل فترة بسبب الموارد، فالمشكلة ليست في الموقع بل في حجم الخادم أو إعداداته. إدارة وتأمين الخادم تغطي المراقبة والنسخ الاحتياطي وضبط الموارد، بدل التعامل مع كل عطل كحالة طارئة.

الدقيقة 7–8: اعزل آخر تغيير

بعد التأكد من أن الخادم يعمل، اسأل: ما الذي تغيّر قبل التوقف؟ التحديثات هي السبب الأكثر شيوعاً، ويليها نشر كود أو تغيير صلاحيات أو تعديل DNS.

في ووردبريس، عطّل الإضافات بإعادة تسمية مجلدها بدل حذفها:

bash
mv wp-content/plugins/plugin-name wp-content/plugins/plugin-name.off

وإن كانت المشكلة في القالب، فعّل قالباً افتراضياً مؤقتاً. يمكنك فعل ذلك من لوحة التحكم إن كانت تعمل، أو عبر WP-CLI:

bash
wp plugin deactivate plugin-name
wp theme activate twentytwentyfour

افحص أيضاً:

bash
ls -la /path/to/site/.maintenance
ls -la /path/to/site/wp-content/

وجود .maintenance يعني أن الموقع في وضع الصيانة، وليس معطلاً. وإن كانت الصلاحيات تغيّرت بعد نقل أو استعادة، فقد يمنع الخادم قراءة الملفات. راجع مالك الملفات وصلاحياتها قبل إعادة التثبيت. مبرمج ووردبريس يستطيع تحديد التعارض بدقة إن كان الموقع يعتمد على تخصيصات كثيرة.

الدقيقة 9: قرار الإصلاح أو الاستعادة أو النقل

الآن أصبح لديك ما يكفي لاتخاذ قرار، بدل التجربة العشوائية.

  • الإصلاح المباشر: مناسب إن كان السبب واضحاً ومحدوداً، مثل إضافة معطلة أو قرص ممتلئ أو شهادة منتهية.
  • الاستعادة من نسخة: مناسبة إن تلفت قاعدة البيانات أو فقدت ملفات، لكن بعد معرفة السبب وأخذ نسخة من الحالة الحالية.
  • النقل إلى خادم آخر: مناسب فقط إن كان الخادم أو الاستضافة هي عنق الزجاجة. نقل المواقع بدون توقف يحتاج تخطيطاً واختباراً، وليس مجرد نسخ ملفات.
  • التعامل كاختراق: إن ظهرت إعادة توجيه غريبة أو حسابات غير معروفة أو ملفات جديدة، فراجع 9 علامات اختراق الموقع ثم ابدأ بـإنقاذ الموقع المخترق قبل أي استعادة.
خطر

لا تستعد نسخة احتياطية فوق موقع مخترق دون تنظيف. ستعيد الملفات الخبيثة نفسها، ويعود الاختراق خلال أيام.

الدقيقة 10: أعد الخدمة ثم امنع التكرار

بعد عودة الموقع، لا تغلق الملف فوراً. اختبر ما لا يراه المستخدم عادةً: الفورمات، الدفع، البريد، روابط SEO، وشهادة SSL.

قائمة تحقق بعد الإصلاح:

  1. افتح الرئيسية وصفحة داخلية وصفحة منتج أو مقال.
  2. أرسل نموذج تواصل تجريبياً وتأكد من وصول البريد.
  3. اختبر عملية دفع صغيرة إن كان متجراً.
  4. أعد تفعيل الإضافات واحدة تلو الأخرى، واختبر بعد كل واحدة.
  5. راجع سجلات الأخطاء 24 ساعة بعد الإصلاح.
  6. خذ نسخة احتياطية جديدة بعد الاستقرار.
  7. فعّل مراقبة خارجية تنبهك قبل أن يشتكي العميل.
  8. ثبّت نسخاً احتياطية يومية واختبر الاستعادة، لا إنشاء النسخة فقط.

ماذا تجهّز قبل طلب المساعدة؟

سواء أصلحت الموقع بنفسك أو طلبت من فريق متخصص، هذه المعلومات تختصر نصف الوقت:

  • وقت بدء العطل وأول صفحة لاحظت فيها المشكلة.
  • آخر تغيير حدث قبل التوقف: تحديث، نشر، نقل، أو تعديل DNS.
  • رمز الاستجابة من فحص خارجي، ولقطة شاشة للخطأ إن ظهر.
  • آخر 30 سطراً من سجل Nginx أو PHP، بعد إخفاء أي بيانات حساسة.
  • وصول آمن إلى لوحة التحكم أو SSH إن كان متاحاً، دون إرسال كلمات المرور في محادثة مفتوحة.
  • نسخة احتياطية من الملفات وقاعدة البيانات، أو تأكيد أن مزوّد الاستضافة يوفرها.
  • ما جرّبته بالفعل وما تغيّر بعد كل محاولة، حتى لا يتكرر نفس الإجراء.

هذه القائمة لا تجعل التشخيص أسرع فقط، بل تمنع تعديلات متعارضة تُصعّب استعادة الموقع لاحقاً.

قائمة التحقق النهائية

  • تأكدت أن الموقع متوقف من شبكة أخرى.
  • سجلت آخر تغيير قبل التوقف.
  • قرأت رمز الاستجابة قبل أي إصلاح.
  • راجعت سجلات Nginx وPHP وووردبريس.
  • فحصت المساحة وinodes والذاكرة وحالة الخدمات.
  • عزلت آخر إضافة أو قالب أو نشر كود.
  • أخذت نسخة من الحالة الحالية قبل أي استعادة.
  • استعدت الخدمة واختبرت الفورمات والدفع والبريد.
  • راقبت السجلات بعد الإصلاح.
  • فعّلت خطة تمنع تكرار العطل.

إن كان الموقع متوقفاً الآن وتريد أن يتولى أحد التشخيص بدلاً منك، إصلاح المواقع المتوقفة يبدأ بالعزل والنسخة الاحتياطية قبل أي تعديل، وينتهي بخطة تمنع التكرار.

تحتاج تنفيذ هذا عملياً؟

راسلنا على واتساب وسنحوّل هذا المقال إلى خطة عمل واضحة لموقعك.

تواصل عبر واتساب