خطأ 502 متكرر يستدعي فحص العلاقة بين الجهة التي تستقبل طلب المستخدم والخدمة الخلفية التي يفترض أن تجيبها. قد يكون التطبيق متوقفاً، أو عنوان الاتصال غير صحيح، أو الاتصال يُغلق قبل اكتمال الرد. لا تعالج الحالة برفع المهلة أو إعادة تشغيل كل الخدمات قبل ربط الخطأ بسجل البوابة وحالة التطبيق في اللحظة نفسها.
تصف وثائق HTTP رمز 502 بأنه مشكلة في الرد الذي تلقته بوابة من خادم خلفي. أما 504 فيرتبط بعدم وصول رد في الوقت المطلوب. قد تعرض المنصات الأخطاء بطرق مختلفة، لذلك اعتمد الرمز والسجل الفعليين ولا تستخدم وصف «مهلة» لكل 502.
حدد أي بوابة أصدرت الخطأ
قد يمر الطلب عبر CDN ثم موازن حمل ثم Nginx ثم PHP-FPM أو تطبيق Node.js. حدد الطبقة التي سجلت الخطأ وما إذا وصل الطلب إلى التي بعدها. وجود صفحة تحمل شعار وسيط لا يثبت وحده سبب العطل؛ تحتاج سجلات وتوقيتاً ومعرف طلب عندما يكون متاحاً.
سجل هل يحدث الخطأ لكل المسارات أم لطلب طويل أو رفع ملف أو أثناء النشر. وإذا كان يظهر لبعض الطلبات فقط، قارن العقد الخلفية التي استقبلتها. قد تكون نسخة واحدة معطلة داخل مجموعة سليمة في معظم الوقت.
اربط رسالة الخطأ بحالة الخدمة الخلفية
افحص سجل البوابة وسجل التطبيق ومدير العمليات في نافذة زمنية قصيرة. رفض الاتصال يختلف عن إغلاقه مبكراً أو وصول رد غير صالح. تحقق هل أعيد تشغيل العملية أو انتهت بسبب خطأ أو ذاكرة، وهل بدأ الاستماع قبل أن يوجّه الموازن إليها الطلبات.
| ما يذكره السجل | الفرضية التي تُفحص | الدليل المطلوب |
|---|---|---|
| رفض اتصال بالخلفية | عملية غير مستمعة أو وجهة أو منفذ غير صحيح | حالة الخدمة ونقطة الاستماع والإعداد الفعلي |
| إغلاق مبكر أو إعادة ضبط اتصال | خروج عامل أو توقف تطبيق أثناء الطلب | سجل التطبيق وأحداث العملية والموارد |
| رد أو ترويسة غير صالحة | بروتوكول غير مناسب أو إخراج غير متوقع | إعداد الوكيل ونوع الخدمة والطلب المعني |
| فشل مرتبط بعقدة محددة | نسخة أو إعداد أو اعتماد مختلف | مقارنة الجاهزية والإصدار والاتصالات بين العقد |
| انتهاء مهلة موثق | تأخر تنفيذ أو اتصال في طبقة معينة | زمن كل مرحلة ورمز الرد والسياسة المطبقة |
تعامل مع الجدول كمسار فحص، وليس تشخيصاً نهائياً من نص واحد. قد يعكس الخطأ الأول عرضاً لسبب أعمق، مثل عامل يموت من ضغط ذاكرة ثم يرفض الاتصال لاحقاً.
تحقق من العنوان والبروتوكول والصلاحيات
راجع عنوان upstream أو مسار Unix socket، ونوع البروتوكول الذي تتوقعه البوابة. خدمة HTTP تختلف عن PHP-FPM الذي يستخدم FastCGI؛ لا تختبرهما بالطريقة نفسها ثم تعتبر غياب رد HTTP دليلاً على تعطل FPM. وفي الحاويات، تحقق من أن الاسم والعنوان يتوافقان مع النشر الحالي.
إذا كان الاتصال عبر socket، افحص صلاحية العملية التي تحاول الوصول إليه. وإذا كان عبر شبكة داخلية، راجع المسار والسياسة المطلوبة تحديداً. لا تفتح منفذ التطبيق للعالم أو تعطل الجدار كله لاختبار فرضية؛ نفذ اختباراً محدوداً من سياق البوابة أو عبر مسؤول مخول.
راجع توقف العمليات وحدود العمال
في PHP-FPM، توضح وثائق الإعداد الرسمية حدود عمليات الخدمة وخيارات إنهاء الطلبات والتسجيل. يراجع المسؤول امتلاء السعة والتوقفات والمهل مع الذاكرة المتاحة، لا يضاعف pm.max_children تلقائياً حتى لا يحول الانتظار إلى نفاد ذاكرة.
وفي Node.js أو تطبيق مشابه، افحص عدد مرات إعادة التشغيل وسبب الخروج والإصدار المستخدم. نجاح مدير العمليات في إعادة الخدمة لا يمحو الطلبات التي تعطلت أثناء غيابها. إذا تكرر ذلك تحت حمل معين، اتبع سبب الخروج قبل زيادة المهل في البوابة.
لا ترفع المهلة قبل فهم معناها وسبب بلوغها
توضح وثائق وكيل Nginx أن proxy_read_timeout يخص الفترة بين عمليات القراءة المتعاقبة، لا زمناً إجمالياً بسيطاً لكل الرد. وقد توجد مهل أخرى في CDN أو التطبيق أو قاعدة البيانات. حدد أيها انتهت أولاً وما الذي كان الطلب ينتظره.
قد تكون زيادة مدروسة مناسبة لعملية مشروعة طويلة، لكن إذا كان التطبيق ينتظر خدمة متعطلة فستطيل احتجاز الموارد. ناقش نقل العمل الطويل إلى مهمة قابلة للتتبع عندما يناسب الوظيفة. ويجب أن تكون حدود الطبقات متسقة مع تجربة المستخدم وسلامة العملية.
افحص النشر والتوقف المنظم
إذا يظهر 502 عند كل تحديث، راجع هل تتوقف النسخة القديمة قبل جاهزية الجديدة، وكيف يتوقف استقبال طلبات جديدة وكيف تُستكمل الطلبات الجارية. قد تحتاج تسلسل نشر أو فحص جاهزية أفضل بدلاً من سيرفر أقوى.
اختبر دورة نشر في بيئة ممثلة مع طلبات قراءة وكتابة تجريبية. تحقق من أن تحديث العنوان أو الشهادة أو الإعداد يصل لكل طبقات التوجيه، وأن بعض النسخ لا تبقى على إعداد قديم. وفي بيئة متعددة العقد، سجل النسخة التي أصدرت الخطأ لتجنب إخفائه خلف نجاح بقية الطلبات.
راجع إعادة المحاولة حتى لا تتكرر المعاملة
قد تستطيع بوابة إعادة طلب إلى عقدة أخرى وفق إعدادها، لكن الطلب الذي ينشئ أثراً تجارياً يحتاج عناية خاصة. ربما نفذ التطبيق المعاملة ثم فقد الاتصال قبل إرسال الرد. لا تفعّل إعادة كل طلبات الكتابة دون التحقق من تصميم منع التكرار وحالة العملية.
استخدم بيانات اختبار عند محاكاة انقطاع أثناء إنشاء طلب، وتحقق من النتيجة في القاعدة أو الخدمة المعنية. سرعة عودة صفحة نجاح لا تكفي إذا أُنشئت معاملتان. يجب أن يتشارك المطور ومسؤول الوكيل في اعتماد سياسة الإعادة.
متى تحتاج ترقية أو إدارة خادم ويب؟
إذا ثبت أن حملاً مشروعاً يملأ قدرة العمال أو يسبب توقفات موارد بعد معالجة الهدر، فاختبر زيادة مناسبة أو توزيع الخدمة. أما إذا كان السبب عنوان socket خاطئاً أو نشرًا غير متسق، فالعلاج في الإعداد والتشغيل. اطلب من التقييم تحديد هذا الفرق قبل تغيير الباقة.
في مثال افتراضي، فشل عقدة واحدة بعد تحديث يعالج بتصحيحها والتحقق من الجاهزية. وفي خدمة أخرى تموت عمليات تحت ذروة ذاكرة، فتحتاج تشخيص الذاكرة وضبط التزامن وربما ترقية. الرمز واحد لكنه لا يحدد نوع الشراء بمفرده.
تحقق من الحل على المسار الكامل
أعد الاختبار عبر النطاق والوسطاء المعتادين، وراقب الأخطاء والاتصالات وإعادة تشغيل العمليات تحت حمل ممثل. راجع حفظ البيانات وإعدادات الرجوع وفق أخطاء النسخ الاحتياطي. وإذا لزم النقل، أضف توجيه upstream والجاهزية والتوقف المنظم إلى خطة نقل الاستضافة.
لا تغلق البلاغ لمجرد اختفاء الخطأ بعد إعادة تشغيل. وثّق السبب والتعديل والمدة التي شملت الذروة أو النشر الذي كان يعيد المشكلة، مع تنبيه يكشف تكرارها.
أسئلة شائعة عن خطأ 502 متكرر
هل 502 يعني انتهاء مهلة دائماً؟
لا. قد يكون رفض اتصال أو رد غير صالح أو إغلاق مبكر. افحص السجل، وميّز الحالة عن 504 وسياسات المنصة المستخدمة.
هل أعيد تشغيل Nginx والتطبيق معاً؟
قد يعيد ذلك الخدمة مؤقتاً لكنه يصعّب معرفة السبب. اجمع الأدلة وحدد المكون المتأثر، ثم نفذ إجراءً محدوداً بأثر معلوم.
هل زيادة عمال PHP تمنع الخطأ؟
فقط إذا كانت السعة هي القيد وتكفي الموارد للزيادة. راجع الذاكرة والتزامن والتوقفات قبل تغيير العدد.
اطلب فحصاً للاتصال بين البوابة والتطبيق
راجع إدارة خوادم الويب، وأرسل توقيت 502 ورسالة السجل وبنية التوجيه وحالات إعادة التشغيل عبر طلب عرض سعر. اطلب خطة إصلاح للإعداد أو النشر أو الموارد، مع اختبار يثبت استقرار الطلبات وسلامة المعاملات.