خطأ 500 و502: الفرق بينهما وكيف تصلح كل واحد؟

موجز: تخيل مطعماً. خطأ 500 يعني أن الطلب وصل إلى المطبخ لكن الطباخ أفسد الطبق. وخطأ 502 يعني أن النادل وقف عند باب المطبخ ولم يجد من يسلّمه الطبق. في الحالتين يرى الزائر خطأً، لكن مكان العطل مختلف تماماً — وبالتالي الإصلاح مختلف.

500 أم 502؟ ابدأ من مكان الخلل

الخطأان يظهران للزائر بالشكل نفسه تقريباً، لكن مصدرهما مختلف. معرفة من أصدر الرمز تختصر نصف زمن التشخيص.

افحص الرمز من خارج المتصفح أولاً:

curl -sS -o /dev/null -w "HTTP %{http_code} | %{time_total}s\n" https://your-site.com
curl -sSI https://your-site.com | head -n 8

السطر Server: يخبرك هل الرد من Nginx أم Apache أم Cloudflare. هذه معلومة مهمة: .htaccess يؤثر في Apache فقط، ولا يقرأه Nginx إطلاقاً. إن كنت تبحث عن سبب 500 في ملف .htaccess بينما خادمك Nginx، فأنت تصلح ملفاً لا علاقة له بالمشكلة.

500: الطلب وصل والكود فشل

خطأ 500 يعني أن الخادم فهم الطلب لكن التطبيق انهار أثناء تنفيذه. الأسباب الشائعة:

• خطأ قاتل في PHP بعد تحديث إضافة أو قالب أو كود مخصص.
• تعارض بين إضافتين، أو كود قديم لا يعمل مع إصدار PHP الجديد.
• استهلاك ذاكرة يتجاوز الحد المسموح، فيتوقف التنفيذ.
• صلاحيات ملفات خاطئة بعد نقل أو استعادة.
• اتصال قاعدة البيانات مفقود أو تالف.
• ملف .htaccess خاطئ على Apache فقط.

ابدأ بالسجل:

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

في ووردبريس، لا تعرض الأخطاء للزوار. فعّل التسجيل إلى ملف فقط:

define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);

بعد قراءة الخطأ، أعد WP_DEBUG إلى false. ترك الرسائل ظاهرة للزوار يكشف مسارات الملفات وإصدارات المكتبات، وقد يمنح المهاجم خريطة لثغرات موقعك.

إن كان 500 على كل الصفحات: ابحث عن خطأ في التحميل الأول: قاعدة البيانات، ملف functions.php، إضافة أساسية، أو صلاحيات. وإن كان على صفحة واحدة: فالسبب غالباً في كود تلك الصفحة أو إضافة تعمل عند فتحها فقط.

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

502: الوسيط لم يجد من يجيب

خطأ 502 يعني أن Nginx (أو Cloudflare) أرسل الطلب إلى PHP-FPM ولم يستلم رداً صالحاً. الخادم نفسه قد يكون يعمل، لكن الخدمة التي تنفّذ PHP لا تجيب.

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

• خدمة PHP-FPM متوقفة أو انهارت.
• مجمّع PHP-FPM وصل إلى الحد الأقصى من العمليات.
• مقبس Unix غير موجود أو بصلاحيات خاطئة أو بإصدار PHP مختلف.
• مهلة قصيرة جداً بين Nginx وPHP-FPM.
• جدار حماية يمنع Cloudflare من الوصول إلى الخادم الأصلي.

افحص الخدمة والمقبس (استبدل 8.3 بإصدار PHP المثبت لديك في الأوامر والمسارات التالية):

systemctl status php8.3-fpm
nginx -t
ls -l /run/php/php8.3-fpm.sock
tail -n 80 /var/log/nginx/error.log

ابحث في السجل عن عبارات مثل connect() failed أو no live upstreams أو upstream timed out. هذه العبارات تحدد إن كانت المشكلة في المقبس أو في زمن الاستجابة.

تأكد أن إعداد Nginx يشير إلى المقبس الصحيح:

upstream php {
    server unix:/run/php/php8.3-fpm.sock;
}

إن كان السجل يقول server reached pm.max_children، فالمشكلة في عدد العمليات أو في استهلاك كل عملية للذاكرة. لا ترفع الرقم عشوائياً؛ ارفعه بعد قياس الذاكرة المتاحة، وإلا تحولت المشكلة إلى نفاد ذاكرة يوقف الخادم كله.

إعادة التشغيل ليست خطوة أولى:

# بعد قراءة السجل وتأكيد أن الخدمة متوقفة أو معلّقة
systemctl restart php8.3-fpm

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

مثالان من السجل: كيف يبدو السبب؟

السجل لا يعطيك اسماً جاهزاً للسبب، لكنه يعطيك دليلاً قاطعاً على الطبقة التي فشلت.

مثال خطأ 500:

PHP Fatal error: Allowed memory size of 134217728 bytes exhausted
(tried to allocate 20480 bytes) in /wp-content/plugins/example.php

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

مثال خطأ 502:

connect() to unix:/run/php/php8.3-fpm.sock failed
(2: No such file or directory) while connecting to upstream

المعنى أن Nginx يبحث عن مقبس PHP بإصدار لم يعد موجوداً، غالباً بعد ترقية PHP. الحل ليس إعادة تشغيل Nginx، بل تحديث مسار المقبس في إعداد الموقع إلى الإصدار الفعلي، ثم nginx -t وإعادة التحميل.

أخطاء شائعة تزيد المشكلة

• تجربة التعديلات على الإنتاج مباشرة: غيّر على نسخة تجريبية، أو خذ نسخة كاملة قبل أي تعديل.
• تعطيل كل الإضافات دفعة واحدة: يصعب معرفة السبب، وقد يعطل المتجر أو الدفع. عطّل واحدة تلو الأخرى.
• ضبط الصلاحيات على 777: يفتح ثغرة أمنية ولا يحل مشكلة PHP غالباً. استخدم 755 للمجلدات و644 للملفات.
• عرض رسائل الخطأ للزوار: يكشف المسارات وإصدارات المكتبات. سجّل الخطأ في ملف وأخفِ التفاصيل.
• إعادة التشغيل قبل القراءة: قد تعيد الخدمة مؤقتاً وتطمس سبب التوقف، فيتكرر العطل بعد ساعات.

سيناريوهات تحدد المسار بسرعة

• ظهر بعد تحديث إضافة أو قالب: ابدأ بعزل آخر تحديث، لا بإعادة التثبيت.
• ظهر بعد ترقية PHP: راجع سجل الأخطاء بحثاً عن دوال محذوفة أو كود غير متوافق، وارجع لإصدار PHP السابق مؤقتاً إن لزم.
• يظهر في الذروة فقط: المشكلة في الموارد أو مجمّع PHP-FPM أو استعلامات بطيئة، وليست في الكود بالضرورة.
• ظهر بعد نقل أو تغيير DNS: افحص المقبس والصلاحيات وشهادة SSL، فقد تغيّر مسار الجلسات أو الملفات.
• يظهر مع إعادة توجيه أو ملفات غريبة: تعامل مع الحالة كاختراق محتمل، وراجع 9 علامات اختراق الموقع قبل أي إصلاح. إنقاذ المواقع المخترقة يغطي هذا المسار.

خطة إصلاح آمنة في خمس خطوات

1. خذ نسخة احتياطية من الملفات وقاعدة البيانات قبل أي تعديل.
2. ثبّت الرمز والوقت الذي بدأ فيه العطل، وأول صفحة لاحظتها.
3. اقرأ السجل وابحث عن أول خطأ حقيقي، لا عن آثاره المتسلسلة.
4. اعزل آخر تغيير بإعادة تسمية إضافة أو قالب أو الرجوع إلى إصدار سابق.
5. اختبر وراقب بعد الإصلاح: الصفحات، الفورمات، الدفع، والبريد.

متى تحتاج تدخلاً متخصصاً؟

اطلب مساعدة متخصصة إذا تكرر 502 في الذروة بعد ضبط الموارد، أو ظهر 500 دون سجل واضح، أو اشتبهت في تلف قاعدة البيانات أو اختراق. كذلك إن كان الموقع يعتمد على كود مخصص قديماً ولا يوجد وقت لاختبار التغييرات.

إصلاح المواقع المتوقفة يبدأ بتشخيص السبب وأخذ نسخة، ثم استعادة الخدمة، وينتهي بخطة تمنع التكرار. وإن كان الخادم نفسه يتوقف باستمرار، فـإدارة وتأمين الخادم تغطي المراقبة والموارد والنسخ اليومي.

بطاقة القرار السريعة

إن لم تكن متأكداً من الرمز أو من أين تبدأ، ابدأ بـقائمة فحص التوقف في 10 دقائق، ثم عُد إلى هنا لتحديد مسار 500 أو 502. وإن أردت أن يتولى أحد التشخيص، فـإصلاح المواقع المتوقفة يبدأ من السجل لا من التخمين.