502 خطأ انتهاء مهلة البوابة غير الصالحة

أنت تطّلع على مستندات Apigee Edge.
انتقل إلى مستندات Apigee X. معلومات

المشكلة

يتلقى تطبيق العميل خطأ 502 مدخل غير صالح. يعرض "معالج الرسائل" هذا الخطأ لتطبيق العميل عندما لا يتلقّى ردًا من خادم الخلفية.

رسالة الخطأ

يتلقّى تطبيق العميل رمز الاستجابة التالي:

HTTP/1.1 502 Bad Gateway

بالإضافة إلى ذلك، قد تلاحظ رسالة الخطأ التالية:

{
 "fault": {
    "faultstring":"Bad Gateway",
    "detail":{
        "errorcode":"messaging.adaptors.http.flow.BadGateway"
    }
 }
}

السبب المحتمل

في الجدول التالي، يتم إدراج السبب المحتمَل لهذه المشكلة:

السبب: انتهاء مهلة تأكيد الاتصال ببروتوكول أمان طبقة النقل (TLS) أو طبقة المقابس الآمنة (SSL)

في Apigee Edge، يمكنك إعداد اتصال بروتوكول أمان طبقة النقل (TLS) أو طبقة المقابس الآمنة (SSL) بخادم الخلفية لتفعيل اتصالات بروتوكول أمان طبقة النقل بين "معالج رسائل Edge" وخادم الخلفية.

يتضمن تبادل تأكيد الاتصال ببروتوكول TLS/SSL خطوات متعددة. يحدث هذا الخطأ عادةً عند انتهاء مهلة بدء الاتصال ببروتوكول TLS/SSL بين "معالج الرسائل" وخادم الخلفية.

التشخيص

يوضّح هذا القسم كيفية تشخيص مهلة تأكيد الاتصال بطبقة النقل الآمنة (TLS) أو بروتوكول طبقة المقابس الآمنة (SSL) بشكل صحيح. تم إدراج التعليمات المتعلّقة بميزتَي Edge Private Cloud وPublic Cloud.

التحقيق في نتائج جلسة التتبُّع

توضّح الخطوات التالية كيفية إجراء تشخيص أولي للمشكلة باستخدام أداة Apigee Edge Trace.

1. في واجهة مستخدم Edge، فعِّل جلسة تتبُّع للخادم الوكيل لواجهة برمجة التطبيقات المتأثر.

2. إذا أظهر تتبع طلب واجهة برمجة التطبيقات الذي تعذّر تنفيذه ما يلي، فمن المحتمل حدوث خطأ في مهلة تأكيد اتصال بروتوكول أمان طبقة النقل (TLS)/طبقة المقابس الآمنة (SSL). السبب المحتمل لحدوث الخطأ هو أنّ جدار الحماية لخادم الخلفية يحظر الزيارات من Apigee.

   1. حدِّد ما إذا كان خطأ 502 مدخل غير صالح قد حدث بعد 55 ثانية، وبالتالي هو فترة المهلة الافتراضية التي يتم تعيينها في معالج الرسائل. إذا رأيت أن حدث الخطأ بعد 55 ثانية، فهذا يخبرك بأن المهلة كانت السبب المحتمل للمشكلة.
   2. حدِّد ما إذا كان الخطأ يُظهر الخطأ: messaging.adaptors.http.BadGateway. مرة أخرى، يشير هذا الخطأ عادةً إلى انتهاء المهلة.

   3. إذا كنت تستخدم Edge Private Cloud، دوِّن قيمة الحقل X-Apigee.Message-ID في إخراج التتبُّع كما هو موضّح أدناه. يمكن لمستخدم Private Cloud استخدام قيمة رقم التعريف هذه لإجراء المزيد من تحديد المشاكل وحلّها، كما هو موضّح لاحقًا.

      1. انقر على رمز البيانات المسجَّلة في "إحصاءات Google" في مسار التتبُّع:

         

      2. مرِّر لأسفل وسجِّل قيمة الحقل X-Apigee.Message-ID.

للتأكّد من أنّ مهلة مصافحة TLS/SSL هي سبب الخطأ، اتّبِع الخطوات الواردة في الأقسام التالية استنادًا إلى ما إذا كنت تستخدم "سحابة الجمهور" أو "سحابة خاصة".

خطوات تشخيص إضافية لمستخدمي Edge Private Cloud فقط

إذا كنت تستخدم Apigee Edge Private Cloud، يمكنك تنفيذ الخطوات التالية للمساعدة في التحقُّق من سبب خطأ تأكيد الاتصال. في هذه الخطوة، عليك فحص ملف سجلّ "معالج الرسائل" بحثًا عن المعلومات ذات الصلة. إذا كنت تستخدم Edge Public Cloud، يمكنك تخطّي هذا القسم والانتقال إلى خطوات تشخيص إضافية لمستخدمي السحابة الإلكترونية الخاصة والعامة.

1. تحقَّق ممّا إذا كان بإمكانك الاتصال بخادم الخلفية المحدّد مباشرةً من كلّ من معالجات الرسائل باستخدام الأمر telnet:

   1. إذا كان خادم الخلفية يحلّ عنوان IP واحدًا، استخدِم الأمر التالي:

      telnet BackendServer-IPaddress 443

   2. إذا توصل خادم الخلفية إلى عناوين IP متعددة، فاستخدم اسم المضيف لخادم الخلفية في أمر telnet كما هو موضح أدناه:

      telnet BackendServer-HostName 443

   إذا تمكّنت من الاتصال بخادم الخلفية بدون أي أخطاء، انتقِل إلى الخطوة التالية.

   إذا تعذّر تنفيذ الأمر telnet، عليك العمل مع فريق الشبكة للتحقّق من إمكانية الاتصال بين معالِج الرسائل وخادم الخلفية.

2. راجِع ملف سجلّ "معالج الرسائل" بحثًا عن دليل على تعذُّر تأكيد الاتصال. فتح الملف:

   /opt/apigee/var/log/edge-message-processor/system.log

   وابحث عن معرّف الرسالة الفريد (قيمة X-Apigee.Message-ID التي عثرت عليها في ملف التتبُّع). حدِّد ما إذا كانت تظهر لك رسالة خطأ متعلّقة ببدء الجلسة بمعرّف الرسالة كما هو موضّح أدناه:

   org:xxx env:xxx api:xxx rev:x messageid:<MESSAGE_ID> NIOThread@1 ERROR HTTP.CLIENT -
   HTTPClient$Context.handshakeTimeout() : SSLClientChannel[Connected: Remote:X.X.X.X:443
   Local:X.X.X.X]@739028 useCount=1 bytesRead=0 bytesWritten=0 age=55221ms lastIO=55221ms
   isOpen=true handshake timeout
   

إذا ظهر لك هذا الخطأ في ملف سجلّ معالج الرسائل، يُرجى مواصلة التحقيق. انتقِل إلى خطوات تشخيص إضافية لمستخدمي Edge Private وPublic Cloud.

إذا لم تظهر رسالة تأكيد الاتصال في ملف السجلّ، انتقِل إلى المقالة يجب جمع معلومات التشخيص.

خطوات تشخيص إضافية لمستخدمي Edge Private وPublic Cloud

لتحديد المشكلة بدقة، يمكنك استخدام الأداة tcpdump لتحليل حزم TCP/IP للتأكد من انتهاء المهلة أثناء تأكيد اتصال بروتوكول أمان طبقة النقل (TLS) أو طبقة المقابس الآمنة (SSL).

1. إذا كنت مستخدمًا لـ Private Cloud، يمكنك تسجيل حزم TCP/IP على الخادم الخلفي أو "معالج الرسائل". ويفضَّل أن يتم التقاطها في الخلفية. لأنه يتم فك تشفير الحزم على خادم الخلفية.
2. إذا كنت مستخدمًا في Public Cloud، لن يكون بإمكانك الوصول إلى "معالج الرسائل"، ولكن قد يساعد تسجيل حزم TCP/IP على خادم الخلفية في تحديد المشكلة.

3. بعد تحديد مكان التقاط حزم TCP/IP، استخدم ما يلي: tcpdump لالتقاط حزم TCP/IP.

   tcpdump -i any -s 0 host <IP address> -w <File name>
   

   • إذا كنت تأخذ حزم TCP/IP على خادم الخلفية، فاستخدم البيانات العامة عنوان IP لمعالج الرسائل في الأمر tcpdump. للحصول على مساعدة بشأن استخدام الأمر لفحص حركة بيانات الخادم في الخلفية، اطّلِع على tcpdump.

   • إذا كنت تتلقّى حزم TCP/IP في "معالج الرسائل"، استخدِم عنوان IP العلني لـ "خادم الخلفية" في الأمر tcpdump. للحصول على مساعدة في استخدام الأمر لفحص حركة بيانات معالج الرسائل، يُرجى الاطّلاع على tcpdump.

   • إذا كانت هناك عناوين IP متعددة لخادم الخلفية/معالج الرسائل، عليك تجربة استخدام آخر لأمر tcpdump. يمكنك الرجوع إلى الأداة tcpdump لمزيد من المعلومات حول هذه الأداة للمتغيرات الأخرى من هذا الأمر.

4. حلِّل حزم TCP/IP باستخدام أداة Wireshark أو أداة مشابهة. تعرض لقطة الشاشة التالية حزم TCP/IP في Wireshark.

   

5. لاحِظ في إخراج Wireshark أنّ عملية مصافحة TCP الثلاثية تتم بنجاح في أول 3 حزم.

6. يرسل معالج الرسائل بعد ذلك رسالة "Client Hello" في الحزمة رقم 4.

7. بسبب عدم تلقّي إشعار من خادم الخلفية، يعيد معالِج الرسائل إرسال رسالة "مرحبًا العميل" عدة مرات في الحِزم 5 و 6 و7 بعد الانتظار لفترة زمنية محدّدة مسبقًا.

8. عندما لا يتلقى معالج الرسائل أي إقرار بعد ثلاث محاولات، يتم إرسال الرسالة FIN, ACK إلى خادم الخلفية للإشارة إلى أنّه يغلق الاتصال.

9. كما هو موضح في مثال جلسة Wireshark، نجد أن الاتصال بالخلفية بنجاح (الخطوة رقم 1)، ومع ذلك، انتهت مهلة تأكيد اتصال طبقة المقابس الآمنة (SSL) لأن الواجهة الخلفية لم يستجب الخادم أبدًا.

إذا نفّذت خطوات تحديد المشاكل وحلّها الواردة في هذا الدليل الإرشادي وتبيّن لك أنّه حدث خطأ في مصافحة بروتوكول أمان طبقة النقل (TLS) أو طبقة المقابس الآمنة (SSL) بسبب مهلة، انتقِل إلى قسم الحلّ.

استخدام مراقبة واجهة برمجة التطبيقات لتحديد مشكلة

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

الاطّلاع على نموذج سيناريو يوضّح كيفية تحديد المشاكل المتعلّقة برموز الحالة 5xx في واجهات برمجة التطبيقات وحلّها باستخدام ميزة "مراقبة واجهة برمجة التطبيقات" على سبيل المثال، قد تحتاج إلى إعداد تنبيه لتلقّي إشعار عندما يتجاوز عدد أخطاء messaging.adaptors.http.BadGateway حدًا معيّنًا.

الدقة

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

يُرجى العِلم أنّه يمكن فرض قيود جدار الحماية في طبقات الشبكة المختلفة. من المهم التأكد من إزالة القيود في جميع طبقات الشبكة المتعلقة إلى عناوين IP لمعالج الرسائل لضمان تدفق حركة البيانات بسلاسة بين Apigee Edge وخادم الخلفية.

إذا لم تكن هناك قيود على جدار الحماية و/أو استمرت المشكلة، انتقِل إلى يجب جمع معلومات التشخيص.

يجب جمع معلومات التشخيص

إذا استمرت المشكلة حتى بعد اتّباع التعليمات أعلاه، يُرجى جمع المعلومات التشخيصية التالية. يمكنك التواصل معه ومشاركته مع Apigee Edge Support:

1. إذا كنت من مستخدمي Public Cloud، يُرجى تقديم المعلومات التالية:
   1. اسم المؤسسة
   2. اسم البيئة
   3. اسم الخادم الوكيل لواجهة برمجة التطبيقات
   4. إكمال أمر curl لإعادة إنتاج الخطأ
   5. ملف التتبّع الذي يعرض الخطأ
   6. حزم TCP/IP التي تم التقاطها على خادم الخلفية
2. إذا كنت من مستخدمي Private Cloud، يُرجى تقديم المعلومات التالية:
   1. تم ملاحظة رسالة خطأ كاملة
   2. حزمة الخادم الوكيل لواجهة برمجة التطبيقات
   3. ملف التتبّع الذي يعرض الخطأ
   4. سجلات معالج الرسائل /opt/apigee/var/log/edge-message-processor/logs/system.log
   5. حزم بروتوكول TCP/IP التي تم التقاطها على خادم الخلفية أو "معالج الرسائل"
3. تفاصيل حول الأقسام التي جرّبتها في هذا الدليل الإرشادي وأيّ معلومات أخرى ستساعدنا في إيجاد حلّ سريع لهذه المشكلة