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

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

المشكلة

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

رسالة الخطأ

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

HTTP/1.1 502 Bad Gateway

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

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

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

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

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

السبب: انتهاء مهلة تأكيد الاتصال ببروتوكول أمان طبقة النقل (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 على الخادم الخلفي أو Message Processor. يُفضّل تسجيلها على خادم الخلفي ، لأنّه يتم فك تشفير الحِزم على خادم الخلفية.
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. يُرسِل "معالج الرسائل" بعد ذلك رسالة "مرحبًا العميل" في الحزمة رقم 4.

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

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

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

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

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

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

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

الدقة

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

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

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

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

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

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