ملاحظة
يتطلب الوصول إلى هذه الصفحة تخويلاً. يمكنك محاولة تسجيل الدخول أو تغيير الدلائل.
يتطلب الوصول إلى هذه الصفحة تخويلاً. يمكنك محاولة تغيير الدلائل.
تقدم هذه المقالة أسبابا حول سبب قيام Azure Application Gateway بإرجاع رموز استجابة HTTP محددة. يتم توفير الأسباب الشائعة وخطوات استكشاف الأخطاء وإصلاحها لمساعدتك في تحديد السبب الجذري للخطأ رمز استجابة HTTP. يمكن إرجاع رموز استجابة HTTP إلى طلب عميل ما إذا كان قد تم بدء اتصال بهدف الواجهة الخلفية أم لا.
رموز استجابة 3XX (إعادة توجيه)
يتم تقديم استجابات 300-399 عندما يتطابق طلب العميل مع قاعدة بوابة التطبيق التي تم تكوينها لإعادة التوجيه. يمكن تكوين عمليات إعادة التوجيه على قاعدة كما هي أو عبر قاعدة مخطط المسار. لمزيد من المعلومات، راجع نظرة عامة على عمليات إعادة التوجيه في Application Gateway.
301 إعادة توجيه دائم
يتم تقديم استجابات HTTP 301 عند تحديد قاعدة إعادة توجيه بقيمة دائمة.
302 تم العثور عليها
يتم تقديم استجابات HTTP 302 عند تحديد قاعدة إعادة توجيه بالقيمة Found .
303 راجع غير ذلك
يتم تقديم استجابات HTTP 302 عند تحديد قاعدة إعادة توجيه بقيمة See Other .
307 إعادة توجيه مؤقت
يتم تقديم استجابات HTTP 307 عند تحديد قاعدة إعادة توجيه بالقيمة المؤقتة .
رموز استجابة 4XX (خطأ العميل)
تشير رموز الاستجابة 400-499 إلى مشكلة بدأت من العميل. يمكن أن تتراوح هذه المشكلات من العميل الذي بدأ الطلبات إلى اسم مضيف غير متطابق، ووقت انتهاء مهلة الطلب، والطلب غير المصادق عليه، والطلب الضار، والمزيد.
تجمع بوابة التطبيق المقاييس التي تسجل توزيع رموز الحالة 4xx/5xx لديها آلية تسجيل تسجل معلومات مثل عنوان IP لعميل URI مع رمز الاستجابة. تتيح المقاييس والتسجيل المزيد من استكشاف الأخطاء وإصلاحها. يمكن للعملاء أيضا تلقي استجابة 4xx من وكلاء آخرين بين جهاز العميل وبوابة التطبيق. على سبيل المثال، CDN (شبكة تسليم المحتوى) وموفري المصادقة الآخرين. راجع المقالات التالية للحصول على مزيد من المعلومات.
المقاييس المدعومة من قبل سجلات تشخيص Application Gateway V2 SKU
400 – طلب غير صحيح
تتم ملاحظة رموز استجابة HTTP 400 عادة عندما:
- يتم بدء نسبة استخدام الشبكة غير HTTP / HTTPS إلى بوابة تطبيق مع مستمع HTTP أو HTTPS.
- يتم بدء حركة مرور HTTP إلى وحدة استماع مع HTTPS، مع عدم تكوين إعادة التوجيه.
- تم تكوين المصادقة المتبادلة وغير قادرة على التفاوض بشكل صحيح.
- الطلب غير متوافق مع RFC.
بعض الأسباب الشائعة لطلب أن يكون غير متوافق مع RFC هي:
| الفئة | الأمثلة |
|---|---|
| مضيف غير صالح في سطر الطلب | المضيف الذي يحتوي على نقطتين (example.com:8090:8080) |
| رأس المضيف مفقود | لا يحتوي الطلب على عنوان المضيف |
| وجود حرف مشوه أو غير قانوني | الأحرف المحجوزة ,!. الحل البديل هو ترميزه كنسبة مئوية. على سبيل المثال: ٪& |
| إصدار HTTP غير صحيح | الحصول على /content.css HTTP/0.3 |
| يحتوي اسم حقل الرأس وURI على حرف غير ASCII | GET /«úü¡»¿.doc HTTP/1.1 |
| رأس طول المحتوى مفقود لطلب POST | شرح ذاتي |
| أسلوب HTTP غير صحيح | GET123 /index.html HTTP/1.1 |
| تكرار الرؤوس | Authorization:<base64 encoded content>, Authorization: <base64 encoded content> |
| قيمة غير صحيحة في طول المحتوى | طول المحتوى: abc،Content-Length: -10 |
بالنسبة للحالات التي يتم فيها تكوين المصادقة المتبادلة، يمكن أن تؤدي عدة سيناريوهات إلى إرجاع استجابة HTTP 400 للعميل، مثل:
- يتم تمكين المصادقة المتبادلة ولكن لم يتم تقديم شهادة العميل.
- يتم تمكين التحقق من صحة DN (الاسم المميز) ولا يتطابق DN لشهادة العميل مع DN لسلسلة الشهادات المحددة.
- لا تتطابق سلسلة شهادات العميل مع سلسلة الشهادات المكونة في نهج SSL المحدد.
- انتهت صلاحية شهادة العميل.
- يتم تمكين التحقق من إبطال العميل ل OCSP (بروتوكول حالة الشهادة عبر الإنترنت) ويتم إبطال الشهادة.
- تم تمكين التحقق من إبطال العميل ل OCSP (بروتوكول حالة الشهادة عبر الإنترنت)، ولكن تعذر الاتصال به.
- تم تمكين التحقق من إبطال العميل ل OCSP (بروتوكول حالة الشهادة عبر الإنترنت)، ولكن لم يتم توفير مستجيب OCSP في الشهادة.
لمزيد من المعلومات حول استكشاف أخطاء المصادقة المتبادلة وإصلاحها، راجع استكشاف أخطاء رمز الخطأ وإصلاحها.
401 – غير مصرح به
يتم إرجاع استجابة HTTP 401 غير المصرح بها إلى العميل إذا لم يكن العميل مخولا للوصول إلى المورد. هناك عدة أسباب لإرجاع 401. فيما يلي بعض الأسباب مع الإصلاحات المحتملة.
- إذا كان لدى العميل حق الوصول، فقد يكون لديه ذاكرة تخزين مؤقت مستعرض قديمة. قم بإلغاء تحديد ذاكرة التخزين المؤقت للمستعرض وحاول الوصول إلى التطبيق مرة أخرى.
يمكن إرجاع استجابة HTTP 401 غير المصرح بها إلى طلب فحص AppGW إذا تم تكوين تجمع الواجهة الخلفية باستخدام مصادقة NTLM . في هذا السيناريو، يتم وضع علامة على الواجهة الخلفية على أنها سليمة. هناك عدة طرق لحل هذه المشكلة:
- السماح بالوصول المجهول على تجمع الخلفية.
- قم بتكوين الفحص لإرسال الطلب إلى موقع "مزيف" آخر لا يتطلب NTLM.
- غير مستحسن، لأن هذا لن يخبرنا ما إذا كان الموقع الفعلي خلف بوابة التطبيق نشطا أم لا.
- تكوين بوابة التطبيق للسماح باستجابات 401 باعتبارها صالحة للفحوصات: شروط مطابقة التحقيق.
403 – ممنوع
يتم تقديم HTTP 403 Forbidden عندما يستخدم العملاء وحدات حفظ المخزون WAF (جدار حماية تطبيق الويب) وتكوين WAF في وضع الوقاية. إذا كانت مجموعات قواعد WAF الممكنة أو قواعد WAF المخصصة للرفض تتطابق مع خصائص الطلب الوارد، يتم تقديم استجابة محظورة 403 للعميل.
تتضمن الأسباب الأخرى للعملاء الذين يتلقون 403 استجابات ما يلي:
- أنت تستخدم App Service كواجهة خلفية وتم تكوينها للسماح بالوصول فقط من Application Gateway. يمكن أن يؤدي هذا إلى إرجاع خطأ 403 بواسطة App Services. يحدث هذا عادة بسبب عمليات إعادة التوجيه/ارتباطات href التي تشير مباشرة إلى App Services بدلا من الإشارة إلى عنوان IP لبوابة التطبيق.
- إذا كنت تقوم بالوصول إلى مدونة تخزين وكانت بوابة التطبيق ونقطة نهاية التخزين في منطقة مختلفة، إرجاع خطأ 403 إذا لم يكن عنوان IP العام لبوابة التطبيق مدرجا. راجع منح حق الوصول من نطاق IP على الإنترنت.
404 – لم يتم العثور على الصفحة
يتم إنشاء استجابة HTTP 404 عند تقديم طلب إلى Application Gateway (V2 SKUs) مع اسم مضيف لا يتوافق مع أي من وحدات الاستماع متعددة المواقع المكونة، ولا يوجد وحدة استماع أساسية. تعرف على المزيد حول أنواع المستمعين.
408 – مهلة الطلب
يمكن ملاحظة استجابة HTTP 408 عندما لا تستجيب طلبات العميل إلى وحدة الاستماع الأمامية لبوابة التطبيق في غضون 60 ثانية. يمكن ملاحظة هذا الخطأ بسبب ازدحام حركة المرور بين الشبكات المحلية وAzure، عندما يفحص الجهاز الظاهري حركة المرور، أو يصبح العميل نفسه مثقل.
413 – طلب كيان كبير جدا
يمكن ملاحظة استجابة HTTP 413 عند استخدام Azure Web Application Firewall على Application Gateway ويتجاوز حجم طلب العميل الحد الأقصى لحجم نص الطلب. يتحكم الحد الأقصى لحقل حجم نص الطلب في الحد الإجمالي لحجم الطلب باستثناء أي تحميلات للملفات. القيمة الافتراضية لحجم نص الطلب بمقدار 128 كيلو بايت. لمزيد من المعلومات، راجع حدود حجم طلب جدار حماية تطبيق الويب.
499 – أغلق العميل الاتصال
يتم تقديم استجابة HTTP 499 إذا تم إغلاق طلب العميل الذي يتم إرساله إلى بوابات التطبيق باستخدام v2 sku قبل انتهاء الخادم من الاستجابة. يمكن ملاحظة هذا الخطأ في سيناريوهين. السيناريو الأول هو عند إرجاع استجابة كبيرة إلى العميل وربما يكون العميل قد أغلق التطبيق أو حدثه قبل انتهاء الخادم من إرسال استجابة كبيرة. السيناريو الثاني هو عندما تكون المهلة على جانب العميل منخفضة ولا تنتظر لفترة كافية لتلقي الاستجابة من الخادم. في هذه الحالة، من الأفضل زيادة المهلة على العميل. في بوابات التطبيق التي تستخدم v1 sku، قد يتم رفع رمز استجابة HTTP 0 للعميل الذي يغلق الاتصال قبل انتهاء الخادم من الاستجابة أيضا.
رموز استجابة 5XX (خطأ في الخادم)
تشير رموز الاستجابة 500-599 إلى حدوث مشكلة في بوابة التطبيق أو الخادم الخلفي أثناء تنفيذ الطلب.
500 – خطأ داخلي في الخادم
يجب ألا تعرض بوابة تطبيق Azure 500 رمز استجابة. افتح طلب دعم إذا رأيت هذه التعليمة البرمجية، لأن هذه المشكلة خطأ داخلي للخدمة. للحصول على معلومات حول كيفية فتح حالة دعم، راجع إنشاء طلب دعم Azure.
502 – بوابة غير صحيحة
يمكن أن يكون لأخطاء HTTP 502 عدة أسباب جذرية، على سبيل المثال:
- NSG (مجموعة أمان الشبكة) أو UDR (مسار محدد من قبل المستخدم) أو DNS مخصص يمنع الوصول إلى أعضاء تجمع الخلفية.
- لا تستجيب الأجهزة الظاهرية الخلفية أو مثيلات مجموعات مقياس الجهاز الظاهري لفحص السلامة الافتراضي.
- تكوين غير صالح أو غير صحيح لاختبارات فحص الصحة المخصصة.
- لم يتم تكوين تجمع الواجهة الخلفية لبوابة تطبيق Azure أو فارغا.
- لا تعد أي من الأجهزة الظاهرية أو المثيلات في مجموعة تغيير سعة الأجهزة الظاهرية سليمة.
- طلب مشكلات مهلة أو اتصال مع طلبات المستخدم-Azure Application Gateway V1 SKU إرسال أخطاء HTTP 502 إذا تجاوز وقت استجابة الخلفية قيمة المهلة التي تم تكوينها في إعداد الواجهة الخلفية.
للحصول على معلومات حول السيناريوهات التي تحدث فيها أخطاء 502، وكيفية استكشاف الأخطاء وإصلاحها، راجع استكشاف أخطاء البوابة غير الصالحة وإصلاحها.
504 – مهلة البوابة
أرسلت Azure application Gateway V2 SKU أخطاء HTTP 504 إذا تجاوز وقت استجابة الخلفية قيمة المهلة التي تم تكوينها في إعداد الواجهة الخلفية.
IIS (خادم ويب خدمات معلومات الإنترنت)
إذا كان خادم الواجهة الخلفية هو IIS، فشاهد الحدود الافتراضية لمواقع الويب لتعيين قيمة المهلة. راجع السمة connectionTimeout للحصول على التفاصيل. تأكد من أن مهلة الاتصال في IIS تتطابق أو لا تتجاوز المهلة المحددة في إعداد الخلفية.
Nginx
إذا كان الخادم الخلفي هو Nginx أو Nginx Ingress Controller، وإذا كان يحتوي على خوادم المصدر، فتأكد من nginx:proxy_read_timeout أن قيمة التطابقات أو لا تتجاوز مع تعيين المهلة في إعداد الخلفية.
سيناريوهات استكشاف الأخطاء وإصلاحها
خطأ "ERRORINFO_INVALID_HEADER" في سجلات Access
المشكلة: يعرض سجل Access خطأ "ERRORINFO_INVALID_HEADER" لطلب، على الرغم من أن رمز استجابة الواجهة الخلفية (serverStatus) هو 200. في حالات أخرى، يمكن أن يرجع الخادم الخلفي 500.
السبب: يرسل العميل عنوانا يحتوي على أحرف CR LF.
الحل: استبدل أحرف CR LF ب SP (مسافة بيضاء) وأعد إرسال الطلب إلى Application Gateway.
الخطوات التالية
إذا لم تساعد المعلومات الواردة في هذه المقالة في حل المشكلة، أرسل تذكرة دعم.