حل مشكلة 502 Bad Gateway بعد إعادة تشغيل السيرفر (NGINX وPHP-FPM وNode.js): الدليل الكامل للتشخيص والإصلاح في 2026

يُعد خطأ 502 Bad Gateway من أكثر الأخطاء التي تُربك أصحاب المواقع بعد إعادة تشغيل الخادم (Server Reboot)، خصوصًا في مواقع WordPress، وتطبيقات Laravel، وNode.js، وPython (Gunicorn/Uvicorn)، أو أي تطبيق يعمل خلف NGINX Reverse Proxy.

المشكلة أن الكثير يعتقد أن NGINX هو السبب، بينما في الواقع يكون NGINX يعمل بشكل طبيعي تمامًا، لكن الخدمة الخلفية (Backend Application) لم تبدأ بعد إعادة التشغيل أو توقفت بسبب خطأ ما، فيظهر للمستخدم خطأ 502 Bad Gateway.

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

ما هو خطأ 502 Bad Gateway؟

يعني هذا الخطأ أن:

ولحل خطأ 500 المشابه، راجع: حل خطأ 500 Internal Server Error في ووردبريس: الأسباب و8 حلول مضمونة 2026.

• المتصفح استطاع الوصول إلى NGINX.
• NGINX يعمل بصورة صحيحة.
• لكن NGINX لم يستطع الوصول إلى التطبيق الخلفي (Backend).

أي أن المشكلة ليست في خادم الويب نفسه، وإنما في الخدمة التي يتصل بها.

على سبيل المثال:

Visitor
    │
    ▼
NGINX
    │
    ▼
PHP-FPM

أو

Visitor
   │
   ▼
NGINX
   │
   ▼
Node.js

أو

Visitor
   │
   ▼
NGINX
   │
   ▼
Gunicorn

إذا توقف التطبيق الخلفي لأي سبب سيعرض NGINX الرسالة التالية:

502 Bad Gateway

لماذا تظهر المشكلة بعد إعادة تشغيل السيرفر؟

هذه من أشهر المشاكل التي تواجه مديري السيرفرات.

وخطأ 502 يعني رد غير صالح من الخادم الخلفي؛ للتفاصيل التقنية راجع توثيق MDN لرمز 502.

بعد تنفيذ:

reboot

يبدأ Linux بإعادة تشغيل الخدمات بالتتابع.

أحيانًا:

• يبدأ NGINX أولًا.
• بينما التطبيق الخلفي لم يبدأ بعد.
• أو فشل في الإقلاع.
• أو لم يتم ضبطه ليعمل تلقائيًا.

وهنا يحاول NGINX الاتصال بالمنفذ:

127.0.0.1:3000

أو

127.0.0.1:8000

لكن لا يوجد أي برنامج يستمع على هذا المنفذ.

فتكون النتيجة:

502 Bad Gateway

أشهر أسباب ظهور 502 بعد إعادة تشغيل السيرفر

1. التطبيق الخلفي (Backend) لم يبدأ تلقائيًا

مثل:

• Node.js
• PM2
• Gunicorn
• Uvicorn
• Java
• Go
• Python

إذا كانت الخدمة تعمل يدويًا فقط، فسوف تتوقف بالكامل بعد إعادة تشغيل الخادم.

2. خدمة systemd غير مفعلة

تحقق من حالة الخدمة:

systemctl status myapp

إذا ظهر:

inactive (dead)

أو

failed

فهذا يعني أن الخدمة لم تبدأ تلقائيًا.

3. عدم حفظ عمليات PM2

في تطبيقات Node.js كثير من المطورين يشغلون المشروع باستخدام:

pm2 start app.js

لكنهم ينسون تنفيذ:

pm2 startup
pm2 save

وبالتالي تختفي جميع العمليات بعد إعادة التشغيل.

4. توقف PHP-FPM

في مواقع WordPress يكون السبب غالبًا هو توقف خدمة PHP-FPM.

تحقق منها:

systemctl status php-fpm

إذا كانت الحالة:

failed

فسيعرض NGINX خطأ 502.

5. تغيير المنفذ

قد يكون NGINX يبحث عن التطبيق على:

127.0.0.1:3000

بينما التطبيق يعمل على:

127.0.0.1:5000

وبالتالي يعتبر NGINX أن الخدمة غير موجودة.

6. اختفاء ملف Socket

مثل:

/run/php/php8.3-fpm.sock

أو

gunicorn.sock

إذا لم يتم إنشاؤه بعد إعادة التشغيل، فلن يتمكن NGINX من الاتصال بالخدمة.

7. انهيار التطبيق أثناء الإقلاع

قد يبدأ النظام بالكامل، لكن التطبيق نفسه يتوقف بسبب:

• فشل الاتصال بقاعدة البيانات.
• نقص متغيرات البيئة (Environment Variables).
• خطأ في ملفات الإعدادات.
• مشاكل في صلاحيات الملفات.

كيف تعرف أن NGINX ليس هو المشكلة؟

ابدأ دائمًا بهذا الأمر:

systemctl status nginx

إذا ظهرت الحالة:

active (running)

فهذا يعني أن NGINX يعمل بشكل طبيعي، ويجب الانتقال لفحص الخدمة الخلفية.

فحص سجل أخطاء NGINX

نفذ:

tail -f /var/log/nginx/error.log

قد تجد رسائل مثل:

connect() failed (111: Connection refused)

وهذا يعني أن NGINX حاول الاتصال بالخدمة لكنها لم تكن تعمل.

أو:

upstream prematurely closed connection

أي أن التطبيق انهار أثناء التشغيل.

التحقق من المنافذ المفتوحة

استخدم:

ss -lntp

أو:

netstat -tulpn

إذا لم تجد المنفذ الذي يعمل عليه التطبيق، فهذا يعني أن الخدمة لم تبدأ.

فحص الخدمة الخلفية

مثلاً:

systemctl status myapp

أو:

systemctl status php-fpm

أو:

systemctl status gunicorn

إذا ظهرت الحالة:

failed

فقد وصلت إلى سبب المشكلة.

مراجعة سجلات الخدمة

نفذ:

journalctl -u myapp -xe

أو:

journalctl -u php-fpm

أو:

journalctl -u gunicorn

قد تجد أخطاء مثل:

Permission denied

أو:

Address already in use

أو:

Database connection failed

وهذه الرسائل غالبًا ما تكشف السبب الحقيقي مباشرة.

التحقق من إعدادات NGINX

افتح ملف إعدادات الموقع:

/etc/nginx/sites-enabled/example.conf

وابحث عن:

proxy_pass http://127.0.0.1:3000;

وتأكد أن التطبيق يعمل بالفعل على نفس المنفذ.

إذا كنت تستخدم WordPress

غالبًا يكون السبب هو توقف خدمة PHP-FPM.

أعد تشغيلها:

systemctl restart php-fpm

ثم تحقق من حالتها:

systemctl status php-fpm

إذا كنت تستخدم Laravel

نفذ:

php artisan config:cache

ثم:

php artisan optimize

ثم أعد تشغيل PHP-FPM:

systemctl restart php-fpm

إذا كنت تستخدم Node.js

تحقق من PM2:

pm2 list

إذا ظهر:

No processes

فالحل هو:

pm2 start app.js
pm2 save
pm2 startup

إذا كنت تستخدم Gunicorn

تحقق من الخدمة:

systemctl status gunicorn

ثم راجع السجل:

journalctl -u gunicorn

تحقق من قاعدة البيانات

أحيانًا التطبيق لا يبدأ لأن MariaDB أو MySQL نفسها لم تبدأ.

ولمشاكل قاعدة البيانات، راجع: حل خطأ "Error Establishing a Database Connection" في ووردبريس: 7 حلول مضمونة 2026.

تحقق من ذلك:

systemctl status mariadb

أو:

systemctl status mysql

الحلول الدائمة لمنع تكرار المشكلة

تفعيل الخدمة تلقائيًا

systemctl enable myapp

إعادة تشغيل الخدمة تلقائيًا عند الفشل

داخل ملف الخدمة:

وتوفّر مرام هوست خوادم مُدارة تُشغّل الخدمات الخلفية تلقائيًا بعد إعادة التشغيل، ما يقلّل ظهور 502 Bad Gateway ويبقي موقعك متاحًا.

ولمراقبة موارد الخادم، راجع: لماذا يرتفع استهلاك CPU وRAM في موقعك بدون سبب؟ الأسباب الخفية والحلول في 2026.

/etc/systemd/system/myapp.service

أضف:

Restart=always
RestartSec=5

التأكد من تشغيل الخدمة بعد الشبكة

After=network-online.target

أو:

After=network.target

تشغيل التطبيق بعد قاعدة البيانات

إذا كان التطبيق يعتمد على MySQL أو MariaDB:

After=mysql.service

أو:

After=mariadb.service

استخدام Health Check

قم بإنشاء Endpoint مثل:

/health

لمراقبة التطبيق والتأكد من جاهزيته بعد كل إعادة تشغيل.

استخدام نظام مراقبة

لضمان اكتشاف المشكلة فور حدوثها استخدم أدوات مثل:

• Uptime Kuma
• Zabbix
• Prometheus
• Grafana

خطوات التشخيص خلال أقل من دقيقة

نفذ الأوامر التالية بالترتيب:

systemctl status nginx

systemctl status php-fpm

أو:

systemctl status myapp

ثم:

ss -lntp

ثم:

tail -50 /var/log/nginx/error.log

وأخيرًا:

journalctl -u myapp -n 50

في أغلب الحالات ستتمكن من تحديد سبب المشكلة خلال أقل من دقيقة.

أخطاء شائعة يجب تجنبها

• إعادة تشغيل NGINX فقط دون فحص التطبيق الخلفي.
• عدم استخدام systemctl enable للخدمات.
• تشغيل التطبيقات يدويًا بدلًا من إدارتها عبر Systemd أو PM2.
• تجاهل سجلات النظام والاعتماد فقط على رسالة الخطأ في المتصفح.
• تغيير منفذ التطبيق دون تعديل إعدادات proxy_pass.
• عدم اختبار إعادة تشغيل السيرفر بعد نشر التطبيق.

الخلاصة

يُعد خطأ 502 Bad Gateway بعد إعادة تشغيل السيرفر من أكثر المشاكل شيوعًا في بيئات الاستضافة الحديثة، لكنه في معظم الحالات لا يكون ناتجًا عن خلل في NGINX نفسه، بل بسبب توقف الخدمة الخلفية أو فشلها في العمل بعد إعادة التشغيل.

باختصار، معظم حالات 502 Bad Gateway بعد إعادة التشغيل سببها أن الخدمة الخلفية لم تبدأ تلقائيًا؛ فعّل systemctl enable للخدمات وراقب السجلات، عندها يختفي 502 Bad Gateway نهائيًا.

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

كما أن استخدام أدوات مراقبة مثل Uptime Kuma أو Zabbix مع إعداد Health Checks للتطبيقات يساعد في اكتشاف الأعطال فور حدوثها، مما يحسن استقرار مواقع WordPress وLaravel وNode.js وPython ويقلل من وقت التوقف إلى الحد الأدنى.