لماذا يعيد الوكيل العكسي الخطأ 502 بعد إعادة بناء حاوية؟

إيفا وونغ

IceWhale author

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

Why Does a Reverse Proxy Return 502 After a Container Rebuild?

يعيد الوكيل العكسي حالة 502 بعد إعادة بناء حاوية عندما يتعذر عليه فتح اتصال صالح مع الخدمة الخلفية التي أُعيد بناؤها.

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

تأكد من أن حالة 502 ناتجة عن فشل الاتصال بالخدمة الخلفية

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

تعني حالة 502 أن الوكيل لم يتلقَّ استجابة صالحة من الخدمة الخلفية، لكن تفاصيل الخطأ تحدد ما إذا كان الهدف مفقودًا، أو يتعذر الوصول إليه، أو لا يستمع، أو يستخدم البروتوكول الخطأ. يشير دليل حالي لاستكشاف أخطاء NGINX إلى أن إعادة بناء الحاوية قد تترك الوكيل يستخدم عنوانًا خلفيًا قديمًا إلى أن يتم تحديث تحليل الأسماء أو الإعدادات.

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

قارن هدف الخدمة الخلفية قبل إعادة البناء وبعدها

افحص اسم الحاوية التي أُعيد بناؤها، واسم الخدمة، وعنوان IP الداخلي، والمنفذ المكشوف، والمنفذ المنشور، والأسماء المستعارة للشبكة، واتصالات الشبكة. قارنها بإعدادات الوكيل وبآخر هدف كان يعمل.

تصف مشكلة في nginx-proxy إعادة بناء غيّرت عنوان IP لحاوية التطبيق، بينما واصل الوكيل إرسال الطلبات إلى خدمة خلفية داخل حاوية يتعذر الوصول إليها. ظل النطاق العام صحيحًا، بينما تغيرت هوية الخدمة الخلفية الخاصة فقط.

فضّل استخدام اسم خدمة ثابت في Compose أو اسم مستعار للشبكة بدلًا من عنوان IP للحاوية. وإذا كان تثبيت عنوان IP مقصودًا، فتحقق من أن الخدمة التي أُعيد بناؤها حصلت عليه فعلًا، ومن عدم امتلاك حاوية أخرى لهذا العنوان.

تحقق من استمرار اشتراك الوكيل والتطبيق في شبكة Docker واحدة

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

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

اربط الخدمات عبر Compose بدلًا من الأوامر المنفذة لمرة واحدة، حتى تستمر العلاقة بعد عمليات إعادة البناء. اختبر تحليل DNS ومنفذ الخدمة الخلفية من داخل حاوية الوكيل بعد إعادة إنشاء المكدس.

-15% OFF

ZimaBoard 2 - خادم منزلي صغير لأفكارك الكبيرة

Single board computer zimaboard2

تحقق من منفذ الاستماع الداخلي وعنوان الربط

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

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

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

انتظر جاهزية التطبيق بدلًا من مجرد بدء تشغيل الحاوية

قد تكون الحاوية التي أُعيد بناؤها قيد التشغيل، بينما تمنع عمليات ترحيل قاعدة البيانات أو استردادها، أو تهيئة ذاكرة التخزين المؤقت، أو إنشاء الإعدادات، التطبيقَ من قبول الطلبات. قارن الطابع الزمني لأول حالة 502 بسجلات الفحص وسجلات بدء التشغيل.

توضح مناقشة لاستكشاف أخطاء Grist كيف يمكن لبنية Docker وإعدادات البيئة وجاهزية الخدمة الخلفية أن تتضافر لتسبب حالات 502 مستمرة من جانب الحاوية بعد إعادة البناء.

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

حدّث تحليل الوكيل وأعد بناء المسار الثابت

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

يوفر سير عمل ZimaSpace الخاص بـ عزل تبعية الحاوية المتسببة في فشل إعادة التشغيل المتكرر تشخيصًا مرتبطًا عندما تتوقف الخدمة الخلفية مرارًا بدلًا من بقائها في حالة صحية.

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