كيفية إصلاح أخطاء 500 و502 و503 و504 على موقعك

يعني الخطأ 500 أن كود الموقع نفسه أو سيرفر الويب فشل أثناء معالجة الطلب، وغالبًا يكون السبب خطأ PHP فادحًا (fatal error) أو ملف .htaccess تالفًا أو صلاحيات ملفات خاطئة. ويعني الخطأ 502 أن وسيطًا (proxy) مثل Nginx أو LiteSpeed لم يتلقَّ ردًا صالحًا من PHP-FPM أو من التطبيق الذي يعمل خلفه. أما الخطأ 503 فيعني أن السيرفر محمَّل فوق طاقته أو في وضع الصيانة أو نفدت موارده. ويعني الخطأ 504 أن الخادم الخلفي (backend) استغرق وقتًا أطول من اللازم فتوقف الوسيط عن انتظاره. وفي جميع الحالات، أسرع طريقة للإصلاح هي قراءة سجل الأخطاء، إذ يذكر السبب عادةً في سطر واحد. يغطي هذا الدليل كلًا من الاستضافة المشتركة بلوحة cPanel وVPS يعمل بنظام Ubuntu.

المتطلبات المسبقة

• الاستضافة المشتركة: بيانات الدخول إلى cPanel.
• VPS أو سيرفر مخصص: صلاحية دخول SSH بحساب root أو بمستخدم لديه صلاحيات sudo.
• نسخة احتياطية حديثة، أو إمكانية استعادة نسخة باستخدام JetBackup في cPanel.
• ملاحظة بما تغيّر مؤخرًا، مثل التحديثات أو عمليات النشر أو تعديلات الإعدادات.

ماذا تعني أخطاء 500 و502 و503 و504؟

• 500 Internal Server Error: يصدر عن التطبيق أو سيرفر الويب. من أسبابه المعتادة أخطاء PHP الفادحة، وتوجيهات .htaccess غير الصالحة، ومشكلات الصلاحيات، واستنفاد memory_limit.
• 502 Bad Gateway: يصدر عن الوسيط، مثل Nginx أو LiteSpeed أو Cloudflare. ويعني أن الخادم الخلفي متوقف، أو انهار في منتصف الطلب، أو يستمع على socket مختلف.
• 503 Service Unavailable: يعني أن السيرفر يرفض تنفيذ الطلبات. من أسبابه حدود الموارد في CloudLinux، أو انشغال جميع عمليات PHP (workers)، أو وضع الصيانة، أو توقف إحدى الخدمات.
• 504 Gateway Timeout: يصدر عن الوسيط. ويعني أن الخادم الخلفي يعمل لكنه بطيء جدًا، وكثيرًا ما يرجع ذلك إلى استعلام قاعدة بيانات بطيء أو استدعاء API خارجي أو عملية استيراد طويلة.

1. ما الذي يجب فحصه أولًا؟

• كل الصفحات أم صفحة واحدة؟ إذا كان الموقع بالكامل متأثرًا، فالمشتبه به هو السيرفر أو PHP أو .htaccess. وإذا كان URL واحد فقط هو الذي يفشل، فالمشتبه به هو ذلك السكربت أو الإضافة أو الاستعلام.
• دائم أم متقطع؟ أخطاء 502 و503 و504 المتقطعة تشير عادةً إلى الضغط على السيرفر أو حدود عمليات PHP أو الذاكرة.
• ما الذي تغيّر؟ تحقق مما إذا كان هناك تحديث لإضافة أو قالب، أو تغيير في إصدار PHP، أو نشر لكود جديد، أو تعديل في الإعدادات، أو ارتفاع مفاجئ في الزيارات.

إذا كنت تعرف ما الذي تغيّر، فتراجع عنه أولًا؛ فهذا عادةً أسرع حل.

2. كيف أُصلح هذه الأخطاء على الاستضافة المشتركة بلوحة cPanel؟

اقرأ سجل الأخطاء (Errors)

في cPanel، افتح Metrics » Errors، وستجد فيه أحدث أخطاء سيرفر الويب الخاصة بحسابك. وتحقق أيضًا من وجود ملف باسم error_log داخل public_html أو داخل مجلد السكربت الذي يفشل. وفي حالة WordPress، يمكنك تسجيل أخطاء PHP بإضافة الأسطر التالية إلى wp-config.php فوق سطر "stop editing":

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

ستُكتب الأخطاء بعد ذلك في wp-content/debug.log. أعِد ضبط WP_DEBUG إلى false عند الانتهاء.

اختبر ملف .htaccess

في Files » File Manager، فعّل خيار Show Hidden Files من الإعدادات (Settings)، ثم غيّر اسم public_html/.htaccess إلى .htaccess.bak. إذا عمل الموقع، فهذا يعني أن الملف يحتوي على توجيه غير صالح أو غير مدعوم. أعِد الملف إلى اسمه الأصلي واحذف الإضافات الأخيرة واحدة تلو الأخرى. وفي حالة WordPress، يمكنك أيضًا إعادة إنشاء ملف سليم من Settings » Permalinks » Save Changes.

تحقق من إصدار PHP وحد الذاكرة

كثيرًا ما تتسبب رسالة "Allowed memory size exhausted" أو التغيير الأخير لإصدار PHP في أخطاء 500. على سيرفرات CloudLinux، استخدم Software » Select PHP Version لتغيير الإصدار، وتبويب Options فيها لرفع memory_limit (مثلًا إلى 256M). وإذا لم تكن هذه الصفحة متاحة، فاستخدم Software » MultiPHP Manager وMultiPHP INI Editor. قد تتعطل الإضافات القديمة على إصدار PHP أحدث، لذا ارجع إلى الإصدار السابق للاختبار.

أصلح صلاحيات الملفات (755 / 644)

لدواعٍ أمنية، كثيرًا ما ترفض معالجات PHP تشغيل الملفات القابلة للكتابة من قِبل المجموعة أو الآخرين، مثل 777. يجب أن تكون صلاحيات المجلدات 755 والملفات 644. إذا كانت أداة Advanced » Terminal متاحة في cPanel لديك، فنفّذ:

find ~/public_html -type d -exec chmod 755 {} \;
find ~/public_html -type f -exec chmod 644 {} \;

وإذا لم تتوفر Terminal، فاستخدم خيار Permissions في File Manager على الملفات المتأثرة.

استبعد تعارض الإضافات

غيّر اسم wp-content/plugins إلى plugins.off لتعطيل جميع الإضافات دفعة واحدة. إذا عاد الموقع للعمل، فأعِد المجلد إلى اسمه الأصلي وعطّل الإضافات واحدة تلو الأخرى حتى يعود الخطأ. وكرر الأمر نفسه مع مجلد القالب النشط إذا لزم الأمر.

تحقق من حدود الموارد (503 و508)

افتح Metrics » Resource Usage. إذا وصل حسابك إلى حدود المعالج أو الذاكرة أو العمليات المتزامنة (entry processes)، فسيظهر للزوار الخطأ 503 أو 508. لتخفيف الضغط، فعّل إضافة LiteSpeed Cache، واحظر الروبوتات المسيئة، واحذف مهام cron الثقيلة. وإذا كان الموقع ببساطة قد تجاوز إمكانيات الباقة، فاطلب ترقيتها عبر تذكرة دعم أو فكّر في VPS سحابي.

التراجع عن التغييرات

افتح JetBackup في cPanel واستعد الملفات أو قاعدة البيانات المتأثرة من نسخة احتياطية أُخذت قبل بدء المشكلة.

3. كيف أُصلح هذه الأخطاء على VPS؟

تحقق من الخدمات والسجلات

حدّد أولًا إصدار PHP-FPM لديك. يأتي Ubuntu 24.04 مع PHP 8.3، ويأتي Ubuntu 22.04 مع PHP 8.1، لذا عدّل الأوامر التالية بما يناسب سيرفرك.

systemctl list-units --type=service 'php*-fpm*'
sudo systemctl status nginx --no-pager
sudo systemctl status apache2 --no-pager
sudo systemctl status php8.3-fpm --no-pager
sudo systemctl status mysql --no-pager

ثم اقرأ سجلات سيرفر الويب وPHP-FPM:

sudo tail -n 50 /var/log/nginx/error.log
sudo tail -n 50 /var/log/apache2/error.log
sudo tail -n 50 /var/log/php8.3-fpm.log
sudo journalctl -u php8.3-fpm --since "1 hour ago" --no-pager

502: خدمة PHP-FPM متوقفة أو استُنفدت عمليات الـ pool

إذا ظهر في السجل سطر مثل connect() to unix:/run/php/php8.3-fpm.sock failed، فهذا يعني أن PHP-FPM متوقفة، أو أن Nginx يشير إلى socket خاطئ. أعِد تشغيل PHP-FPM، ثم تأكد من تطابق مساري الـ socket:

sudo systemctl restart php8.3-fpm
grep -R "fastcgi_pass" /etc/nginx/sites-enabled/
grep "^listen" /etc/php/8.3/fpm/pool.d/www.conf

إذا ظهرت في php8.3-fpm.log الرسالة server reached pm.max_children setting، فهذا يعني أن جميع عمليات PHP مشغولة. القيمة الافتراضية في Ubuntu هي 5 فقط. تحقق أولًا من متوسط حجم العملية الواحدة، ثم تأكد من أن حاصل ضرب pm.max_children في هذا الحجم لا يتجاوز الذاكرة RAM المتاحة:

ps -C php-fpm8.3 -o rss= | awk '{s+=$1;n++} END {print s/n/1024 " MB average"}'
sudo cp /etc/php/8.3/fpm/pool.d/www.conf /etc/php/8.3/fpm/pool.d/www.conf.bak
sudo nano /etc/php/8.3/fpm/pool.d/www.conf   # e.g. pm.max_children = 20
sudo php-fpm8.3 -t && sudo systemctl reload php8.3-fpm

504: انتهاء مهلة الخادم الخلفي (upstream timeout)

يظهر في سجل Nginx السطر upstream timed out (110: Connection timed out). الحل الحقيقي هو العثور على الاستعلام البطيء أو الاستدعاء الخارجي المسبب للمشكلة. ولمنح المهام الطويلة المشروعة وقتًا أطول، أضف fastcgi_read_timeout 120s; داخل كتلة location ~ \.php$. أما التطبيقات التي تعمل خلف proxy_pass، مثل n8n أو Node.js، فاستخدم بدلًا من ذلك proxy_read_timeout 120s;. وارفع أيضًا قيمة max_execution_time في /etc/php/8.3/fpm/php.ini بما يتوافق معها، ثم اختبر الإعدادات وأعِد تحميلها:

sudo nginx -t && sudo systemctl reload nginx
sudo systemctl reload php8.3-fpm

امتلاء المساحة أو نفاد الذاكرة

تتحقق الأوامر التالية من المساحة وعدد الـ inodes، وتعثر على أكبر المجلدات حجمًا، وتقلّص سجل النظام (journal)، وتعرض استهلاك الذاكرة وأي عمليات أنهتها النواة (kernel):

df -h
df -i
sudo du -xh / --max-depth=1 2>/dev/null | sort -h | tail -n 10
sudo journalctl --vacuum-size=200M
free -h
sudo dmesg -T | grep -iE "out of memory|killed process"

امتلاء المساحة يمنع MySQL وجلسات PHP من الكتابة. احذف السجلات والنسخ الاحتياطية القديمة لتحرير المساحة. وإذا أوقفت آلية نفاد الذاكرة في النواة (OOM killer) خدمة MySQL أو PHP-FPM، فأعِد تشغيلهما، وخفّض قيمة pm.max_children، وأضف ذاكرة swap أو زِد الذاكرة RAM. وعلى استضافة n8n، يعني الخطأ 502 عادةً أن الحاوية (container) توقفت. تحقق منها باستخدام docker ps -a وdocker logs --tail 100 <container>.

التراجع عن التغييرات

احتفظ دائمًا بنسخة من ملف الإعدادات قبل تعديله. وللتراجع عن أي تغيير، استعد النسخة، ثم اختبر الإعدادات وأعِد تحميلها:

sudo cp /etc/php/8.3/fpm/pool.d/www.conf.bak /etc/php/8.3/fpm/pool.d/www.conf
sudo php-fpm8.3 -t && sudo systemctl reload php8.3-fpm

بالنسبة لعمليات نشر الكود، أعِد نشر الإصدار أو الوسم (tag) السابق. وإذا تعذّر عليك الوصول إلى السيرفر تمامًا، فاطلب تفعيل وضع الإنقاذ (rescue mode) عبر تذكرة دعم.

تحقق من نجاح الإصلاح

تحقق من رمز الحالة وزمن الاستجابة:

curl -sS -o /dev/null -w "%{http_code} %{time_total}s\n" https://example.com/
sudo tail -f /var/log/nginx/error.log

يجب أن ترى 200، أو 301/302 في حالة إعادة التوجيه. اختبر في نافذة تصفح خاصة، وامسح ذاكرة التخزين المؤقت لأي CDN أو لـ LiteSpeed حتى لا ترى صفحة خطأ قديمة مخزّنة مؤقتًا.

مشكلات شائعة

• خطأ 500 مباشرةً بعد تحديث إضافة أو PHP ← عطّل الإضافة بتغيير اسم مجلدها، أو ارجع إلى إصدار PHP السابق.
• خطأ 500 بعد رفع ملفات عبر FTP ← أعِد ضبط الصلاحيات إلى 755 للمجلدات و644 للملفات.
• خطأ 502 متقطع مع ازدياد الزيارات ← تم الوصول إلى حد pm.max_children. ارفعه في حدود الذاكرة RAM المتاحة وأضف تخزينًا مؤقتًا للصفحات.
• خطأ 503 على الاستضافة المشتركة في أوقات الذروة ← تم الوصول إلى حدود الموارد. راجع Resource Usage، وفعّل التخزين المؤقت للصفحات، واحظر الروبوتات الضارة، أو قم بترقية الباقة.
• خطأ 504 عند عمليات الاستيراد أو التقارير فقط ← ارفع قيمتي fastcgi_read_timeout وmax_execution_time، أو انقل المهمة إلى cron أو إلى مهمة تُنفَّذ من سطر الأوامر (CLI).

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

هل يرجع الخطأ 500 إلى موقعي أم إلى السيرفر؟

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

لماذا يُصلح إعادة تشغيل PHP-FPM الخطأ 502 لفترة مؤقتة فقط؟

إعادة التشغيل تُنهي العمليات العالقة لكنها لا تزيل السبب. فالسكربتات البطيئة أو قلة عدد العمليات أو نفاد الذاكرة ستملأ الـ pool مجددًا، لذا عالج السبب الذي تشير إليه السجلات.

هل يمكن أن يتسبب Cloudflare في أخطاء 502 أو 504؟

يعرض Cloudflare هذه الرموز عندما يفشل سيرفرك الأصلي (origin) أو يستجيب ببطء شديد، لذا يكون الحل دائمًا تقريبًا على السيرفر. أوقف Cloudflare مؤقتًا لاختبار السيرفر الأصلي مباشرةً.

هل تحتاج إلى مساعدة؟ افتح تذكرة دعم عبر https://cloudesta.com/submitticket.php مع ذكر الـ URL المتأثر ووقت حدوث الخطأ وأسطر السجل ذات الصلة، وسيتولى فريقنا فحص المشكلة.