خطأ HTTP 502 Bad Gateway: ماذا يعني وكيف تصلحه
الخطأ 502 هو الـ proxy يخبرك أنه لم يحصل على استجابة صالحة من تطبيقك. والإصلاح يقع غالبًا خطوة واحدة خلف الـ proxy.
ماذا يعني خطأ HTTP 502 فعليًا
خطأ HTTP 502 Bad Gateway يعني أن خادمًا يعمل كبوابة أو وكيل — nginx أو HAProxy أو موزّع حمل سحابي أو CDN — استلم استجابة غير صالحة (أو لم يستلم استجابة صالحة أصلًا) من الخادم الخلفي الذي مرّر إليه الطلب. صفحة 502 التي تراها يولّدها الوسيط لا تطبيقك: حاول الـ proxy التحدث إلى التطبيق ففشلت المحادثة.
«الاستجابة غير الصالحة» تشمل عدة أعطال مختلفة: رُفض الاتصال لأن لا شيء يستمع على المنفذ، أو أغلق الخادم الخلفي الاتصال قبل إرسال استجابة كاملة، أو كانت الاستجابة مشوّهة، أو انهارت العملية في منتصف الطلب. وكل حالة تترك بصمة مختلفة في سجل أخطاء الـ proxy، ولهذا يبقى ذلك السجل أهم دليل عند تشخيص 502.
الأسباب الجذرية الشائعة لخطأ 502
التطبيق الخلفي انهار أو لا يعمل
عملية التطبيق ماتت — قتل بسبب نفاد الذاكرة، أو انهيار غير مُعالَج، أو إعادة تشغيل فاشلة بعد نشر — فلا يجد الـ proxy من يتحدث إليه. يسجّل nginx هذا كـ "connect() failed (111: Connection refused) while connecting to upstream".
اتصال مرفوض بين الـ proxy والتطبيق
التطبيق يعمل لكنه لا يستمع حيث يتوقّعه الـ proxy: ارتبط بـ 127.0.0.1 بينما يتصل الـ proxy عبر الشبكة، أو جدار ناري يحجب المنفذ، أو التطبيق ما زال يُقلع ولم يفتح مقبسه بعد. فتُرفض محاولة اتصال الـ proxy مباشرة.
مهلة الخادم الخلفي أقصر من الطلب
وصل عامل التطبيق إلى مهلته الخاصة (مثل gunicorn أو PHP-FPM وهو يقتل عاملًا بطيئًا) وأغلق الاتصال قبل الاستجابة، فيرى الـ proxy رسالة "upstream prematurely closed connection" ويعيد 502. استعلامات قاعدة البيانات البطيئة والنداءات الخارجية الطويلة هي المسبّب المعتاد.
منفذ أو مقبس أو عنوان خلفي خاطئ
إعداد الـ proxy يشير إلى منفذ خاطئ، أو مسار Unix socket غير موجود أو بصلاحيات خاطئة، أو عنوان DNS/حاوية قديم بعد إعادة نشر. كل شيء «يعمل»، ومع ذلك يفشل كل طلب بـ 502 لأن الطرفين لا يلتقيان أبدًا.
كيف تحقّق في خطأ 502 وتصلحه
اعمل من الـ proxy إلى الخلف: حدّد نطاق المشكلة، واقرأ سجل أخطاء الـ proxy لتصنيف العطل، ثم تحقّق من صحة الخادم الخلفي وإعداداته وموارده.
- 1
حدّد النطاق من الخارج
هل كل الطلبات تفشل أم مسار واحد؟ منطقة واحدة أم الجميع؟ دائم أم متقطّع؟ الفشل الكلي يعني أن الخادم الخلفي ميت أو معنون خطأ؛ أما 502 المتقطّع فيشير إلى انهيارات تحت الحمل، أو مهلات عمال، أو خادم واحد معطوب خلف الموزّع.
- 2
اقرأ سجل أخطاء الـ proxy
يخبرك error.log في nginx (أو سجلات موزّع الحمل) أي عطل حدث بالضبط: "connection refused" تعني لا أحد يستمع، و"upstream prematurely closed" تعني أن التطبيق مات أو تجاوز مهلته أثناء الطلب، و"no live upstreams" تعني أن كل الخوادم الخلفية عُلّمت متعطّلة. هذا السطر الواحد يحسم عادة بقية التحقيق.
- 3
افحص صحة عملية التطبيق الخلفي
على خادم التطبيق: هل العملية تعمل (systemctl status أو docker ps أو kubectl get pods)؟ وهل تستمع على المنفذ أو المقبس المتوقّع (ss -lntp)؟ إذا انهارت، فسجلات التطبيق ورمز الخروج يخبرانك بالسبب — قتل نفاد الذاكرة يظهر في dmesg وكرمز خروج 137.
- 4
راجع سجلات التطبيق حول وقت الأعطال
ابحث عن انهيارات أو قتل عمال بسبب المهلة أو حلقات إعادة تشغيل أو أخطاء إقلاع عند أوقات أخطاء 502. مهلة عامل في سجل التطبيق مقترنة بـ "prematurely closed" في سجل الـ proxy تعني أن المشكلة الحقيقية طلب بطيء، لا الـ proxy.
- 5
افحص استنزاف الموارد
ضغط الذاكرة الذي يستدعي قتل العمليات، واستنزاف مجمّعات العمال، وحدود واصفات الملفات، والأقراص الممتلئة — كلها تنتج أخطاء 502 تظهر وتختفي مع الحمل. ومقاييس الخادم عند أوقات الفشل تؤكد ذلك أو تستبعده بسرعة.
- 6
اربط الخطأ بعمليات النشر وتغييرات الإعدادات
أخطاء 502 التي تبدأ تمامًا مع نشر تعني عادة أن الإصدار الجديد يفشل في الإقلاع، أو يرتبط بمنفذ مختلف، أو أن إعداد الـ proxy تغيّر. والتراجع عن النشر هو أسرع تخفيف بينما تشخّص الإصدار الجديد بعيدًا عن الإنتاج.
كيف تمنع أخطاء 502
- استخدم فحوصات صحة على الـ proxy أو موزّع الحمل بحيث لا يُوجَّه المرور إلا إلى خوادم خلفية تقبل الاتصالات فعلًا.
- انشر باستراتيجيات بلا توقّف (تدريجي أو blue-green) بحيث يستمر الإصدار القديم في الخدمة حتى يبدأ الجديد بالاستماع.
- نسّق سلسلة المهلات: مهلة عامل التطبيق ومهلة قراءة الـ proxy ومهلة موزّع الحمل يجب أن تكون مقصودة لا عشوائية.
- راقب ذاكرة الخوادم الخلفية وتشبّع العمال حتى تظهر حالات قتل نفاد الذاكرة واستنزاف المجمّعات قبل أن تتحوّل إلى أخطاء 502.
- شغّل فحوصات تشغيل خارجية على نقاطك العامة — فخطأ 502 هو بالضبط نوع العطل الذي لا يستطيع تتبّع الأخطاء داخل تطبيقك رؤيته.
كيف يساعدك AllStak مع أخطاء 502
الخطأ 502 يتولّد أمام تطبيقك، لذا لن يلتقطه تتبّع الأخطاء داخل التطبيق وحده. تفحص مراقبة التشغيل في AllStak نقاطك من الخارج وتنبّهك لحظة بدء إعادتها أخطاء 502 — مع رموز الاستجابة وأزمنتها — فتعرف بالانقطاع قبل مستخدميك.
بعدها تُظهر مراقبة البنية التحتية ما إذا كان خادم التطبيق استنفد ذاكرته أو ماتت العملية، وتضع السجلات المركزية سطر "connection refused" من الـ proxy بجانب سجل انهيار تطبيقك على خط زمني واحد. هذا الربط — فحص خارجي ومقاييس خادم وسجل proxy وسجل تطبيق — هو ما يحوّل 502 الغامض إلى عملية ميتة محدّدة.
أسئلة شائعة عن HTTP 502
ما الفرق بين 502 و504؟
كلاهما يصدر من الـ proxy لكنهما يصفان عطلين مختلفين في الخادم الخلفي. الخطأ 502 يعني أن الـ proxy استلم استجابة غير صالحة أو مكسورة — اتصال مرفوض، أو اتصال أُغلق مبكرًا، أو رد مشوّه. أما 504 فيعني أن الخادم الخلفي لم يجب أصلًا ضمن مهلة الـ proxy. أي 502 = إجابة سيئة، و504 = لا إجابة في الوقت.
ما الفرق بين 502 و500؟
الخطأ 500 يصدر من تطبيقك نفسه بعد فشل داخلي — أي أن التطبيق استجاب، لكن بخطأ. أما 502 فيصدر من الـ proxy لأن التطبيق فشل في الاستجابة بشكل صالح أصلًا. إذا رأيت 500 فانظر إلى شيفرة التطبيق؛ وإذا رأيت 502 فانظر إلى توفّر التطبيق والاتصال بين الـ proxy والتطبيق.
هل يمكن أن يسبّب الـ CDN خطأ 502؟
نعم. الـ CDN هو نفسه proxy، فيعيد 502 عندما يستلم استجابة غير صالحة من خادم الأصل — وقد يُظهر أيضًا مشاكل اتصاله الخاصة بالأصل (فشل مصافحة TLS، أو جدار ناري يحجب عناوين الـ CDN). تحقّق هل صفحة 502 تحمل هوية الـ CDN أم proxy الخاص بك لتعرف أي قفزة فشلت.
لماذا تظهر أخطاء 502 متقطّعة تحت الضغط فقط؟
تحت الضغط تتشبّع العمال، وتصطدم الطلبات البطيئة بمهلات العمال، ويستدعي ضغط الذاكرة قتل العمليات، وتفيض طوابير الاتصالات — وكل منها ينتج استجابات خلفية مكسورة بين حين وآخر. راجع عدد العمال والذاكرة وقت الذروة وأوقات سجل أخطاء الـ proxy مقابل منحنى مرورك.
استكشف المزيد
حسب إطار العمل
قارن
التقط خطأ 502 القادم قبل مستخدميك
تراقب فحوصات التشغيل في AllStak نقاطك من الخارج بينما تشرح مراقبة البنية التحتية والسجلات ما حدث خلف الـ proxy — في منصّة واحدة.