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

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

المشكلة

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

رسالة الخطأ

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

HTTP/1.1 502 Bad Gateway

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

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

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

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

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

السبب: انتهاء مهلة تأكيد الاتصال عبر طبقة النقل الآمنة/طبقة المقابس الآمنة

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

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

التشخيص

يوضّح هذا القسم كيفية تشخيص انتهاء مهلة تأكيد الاتصال عبر طبقة النقل الآمنة/طبقة المقابس الآمنة بشكلٍ صحيح. ترد التعليمات الخاصة بـ Edge Private Cloud وPublic Cloud.

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

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

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

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

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

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

للتأكّد من أنّ انتهاء مهلة تأكيد الاتصال عبر طبقة النقل الآمنة/طبقة المقابس الآمنة هو سبب الخطأ، اتّبِع الخطوات الواردة في الأقسام التالية، بناءً على ما إذا كنت تستخدم Public Cloud أو Private Cloud.

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

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

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

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

لتحديد المشكلة بشكلٍ أكبر، يمكنك استخدام أداة tcpdump لتحليل حِزم TCP/IP للتأكّد مما إذا حدثت مهلة أثناء تأكيد الاتصال عبر طبقة النقل الآمنة/طبقة المقابس الآمنة.

  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. لأنّه لا يوجد إقرار من خادم الخلفية، يعيد "معالج الرسائل" إرسال الرسالة "Client Hello" عدة مرات في الحِزم 5 و6 و7 بعد الانتظار لفترة زمنية محدّدة مسبقًا.

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

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

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

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

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

اتّبِع خطوات سيناريو نموذجي يوضّح كيفية تحديد المشاكل وحلّها في الأخطاء من الفئة 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. سجلّات "معالج الرسائل" /opt/apigee/var/log/edge-message-processor/logs/system.log
    5. حِزم TCP/IP التي تم التقاطها على خادم الخلفية أو "معالج الرسائل"
  3. تفاصيل حول الأقسام التي جرّبتها في دليل تحديد المشاكل وحلّها هذا وأي معلومات أخرى ستساعدنا في تسريع حلّ هذه المشكلة