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

يتم الآن عرض مستندات Apigee Edge.
انتقِل إلى مستندات Apigee X.
المعلومات

المشكلة

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

رسالة الخطأ

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

HTTP/1.1 502 Bad Gateway

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

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

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

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

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

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

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

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

التشخيص

يوضِّح هذا القسم كيفية تشخيص مهلة تأكيد الاتصال عبر بروتوكول أمان طبقة النقل (TLS) أو طبقة المقابس الآمنة (SSL) بشكل صحيح. ويتم سرد تعليمات 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 في مخرجات التتبُّع كما هو موضَّح أدناه. ويمكن لمستخدم السحابة الإلكترونية الخاصة استخدام قيمة المعرّف هذه لإجراء مزيد من خطوات تحديد المشاكل وحلّها، كما هو موضَّح لاحقًا.

      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 الخاص والعام في السحابة الإلكترونية

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

  1. إذا كنت من مستخدمي السحابة الإلكترونية الخاصة، يمكنك التقاط حزم TCP/IP على الخادم الخلفي أو معالج الرسائل. ويفضَّل أن تلتقطها على خادم الخلفية، لأنه يتم فك تشفير الحزم على الخادم الخلفي.
  2. إذا كنت من مستخدمي Cloud 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)، ولكن انتهت مهلة تأكيد اتصال طبقة المقابس الآمنة لأن خادم الخلفية لم يستجب مطلقًا.

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

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

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

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

درجة الدقّة

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

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

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

ضرورة جمع معلومات التشخيص

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

  1. إذا كنت من مستخدمي "السحابة الإلكترونية العامة"، يُرجى تقديم المعلومات التالية:
    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. تفاصيل عن الأقسام التي جرّبتها في هذا الدليل الإرشادي وأي إحصاءات أخرى ستساعدنا في حلّ هذه المشكلة بسرعة.