Share via

استكشاف مشكلات Azure Front Door الشائعة وإصلاحها

  • مقالة

توضح هذه المقالة كيفية استكشاف مشكلات التوجيه الشائعة التي قد تواجهها في تكوين Azure Front Door وإصلاحها.

رؤوس أخرى لتصحيح أخطاء HTTP

يمكنك طلب Azure Front Door لإرجاع عناوين استجابة HTTP إضافية لتصحيح الأخطاء. لمزيد من المعلومات، راجع رؤوس الاستجابة الاختيارية.

استجابة 503 أو 504 من Azure Front Door بعد بضع ثوان

العرض

  • تنجح الطلبات المنتظمة المرسلة إلى الواجهة الخلفية دون المرور عبر Azure Front Door. يؤدي الانتقال عبر Azure Front Door إلى استجابات خطأ 503 أو 504.
  • يظهر الفشل من Azure Front Door عادةً بعد حوالي 30 ثانية.
  • تظهر أخطاء 503 المتقطعة مع رسالة "ErrorInfo: OriginInvalidResponse."

السبب

يمكن أن يكون سبب هذه المشكلة أحد ثلاثة أشياء:

  • يستغرق أصلك وقتاً أطول من المهلة التي تم تكوينها لتلقي الطلب من Azure Front Door. المهلة الافتراضية هي 30 ثانية.
  • الوقت الذي يستغرقه إرسال استجابة إلى الطلب من Azure Front Door وقتًا أطول من قيمة المهلة.
  • أرسل العميل طلب نطاق بايت برأس Accept-Encoding، ما يعني تمكين الضغط.

خطوات استكشاف الأخطاء وإصلاحها

  • أرسل الطلب إلى أصلك مباشرة دون المرور عبر Azure Front Door. تعرف على المدة التي يستغرقها أصلك عادة للاستجابة.

  • أرسل الطلب من خلال Azure Front Door وتحقق من حصولك على أي استجابات 503. إذا لم يكن الأمر كما هو، فقد لا تكون المشكلة مشكلة مهلة. إنشاء طلب دعم لاستكشاف المشكلة وإصلاحها بشكل أكبر.

  • إذا كانت الطلبات التي تمر عبر Azure Front Door تؤدي إلى رمز استجابة خطأ 503، فكون مهلة استجابة الأصل ل Azure Front Door. يمكنك زيادة المهلة الافتراضية إلى ما يصل إلى 4 دقائق (240 ثانية). لتكوين الإعداد، انتقل إلى صفحة النظرة العامة لملف تعريف Front Door. حدد Origin response timeout وأدخل قيمة بين 16 و240 ثانية.

    إشعار

    تتوفر القدرة على تكوين مهلة استجابة Origin فقط في Azure Front Door Standard/Premium.

    Screenshot of the origin timeout settings on the overview page of the Azure Front Door profile.

  • إذا لم تؤدي زيادة المهلة إلى حل المشكلة، فاستخدم أداة مثل Fiddler أو أداة مطور المستعرض للتحقق مما إذا كان العميل يرسل طلبات نطاق البايت باستخدام عناوين Accept-Encoding . يؤدي استخدام هذا الخيار إلى استجابة الأصل بأطوال محتوى مختلفة.

    إذا كان العميل يرسل طلبات نطاق بايت برؤوس Accept-Encoding، فلديك خياران. الخيار الأول هو تعطيل الضغط على الأصل أو Azure Front Door. الخيار الثاني هو إنشاء قاعدة مجموعة قواعد لإزالة Accept-Encoding من طلب طلبات نطاق البايت.

    Screenshot that shows the Accept-Encoding rule in a rule set.

503 استجابات من Azure Front Door لـ HTTPS فقط

العرض

  • يتم إرجاع أي استجابات 503 فقط لنقاط النهاية التي تم تمكين HTTPS للباب الأمامي في Azure.
  • تنجح الطلبات المنتظمة المرسلة إلى الواجهة الخلفية دون المرور عبر Azure Front Door. يؤدي الانتقال خلال Azure Front Door إلى ظهور 503 استجابة خطأ.
  • تظهر أخطاء 503 المتقطعة مع رسالة "ErrorInfo: OriginInvalidResponse."

السبب

يمكن أن يكون سبب هذه المشكلة أحد ثلاثة أشياء:

  • تجمع الواجهة الخلفية هو عنوان IP.
  • يقوم خادم الواجهة الخلفية بإرجاع شهادة لا تتطابق مع FQDN لتجمع الواجهة الخلفية لـ Azure Front Door.
  • تجمع الواجهة الخلفية هو خادم Azure Web Apps.

خطوات استكشاف الأخطاء وإصلاحها

  • تجمع الواجهة الخلفية هو عنوان IP.

    يجب تعطيل EnforceCertificateNameCheck.

    يحتوي Azure Front Door على مفتاح يسمى EnforceCertificateNameCheck. بشكل افتراضي، يتم تمكين هذا الإعداد. عند التمكين، يتحقق Azure Front Door من أن اسم مضيف تجمع الواجهة الخلفية FQDN يطابق اسم شهادة خادم الواجهة الخلفية أو أحد الإدخالات في ملحق الأسماء البديلة للموضوع.

    • كيفية تعطيل EnforceCertificateNameCheck من مدخل Microsoft Azure:

      في المدخل، استخدم زر تبديل لتشغيل هذا الإعداد أو إيقاف تشغيله في جزء التصميم Azure Front Door (الكلاسيكي).

      Screenshot that shows the toggle button.

      بالنسبة لطبقة Azure Front Door Standard وPremium، يمكن العثور على هذا الإعداد في إعدادات الأصل عند إضافة أصل إلى مجموعة أصل أو تكوين مسار.

      Screenshot of the certificate subject name validation checkbox.

  • يقوم خادم الواجهة الخلفية بإرجاع شهادة لا تتطابق مع FQDN لتجمع الواجهة الخلفية لـ Azure Front Door. لحل هذه المشكلة، لديك خياران:

    • يجب أن تتطابق الشهادة التي تم إرجاعها مع FQDN.
    • يجب تعطيل EnforceCertificateNameCheck.

  • تجمع الواجهة الخلفية هو خادم Azure Web Apps:

    • تحقق مما إذا كان تطبيق Azure على الويب قد تم تكوينه باستخدام SSL المستند إلى IP بدلاً من أن يكون مستنداً إلى SNI. إذا تم تكوين تطبيق الويب على أساس IP، يجب تغييره إلى SNI.
    • إذا كانت الواجهة الخلفية غير صحية بسبب فشل الشهادة، يتم إرجاع رسالة خطأ 503. يمكنك التحقق من صحة الخلفيات على المنفذين 80 و443. إذا كان 443 فقط غير صحي، فمن المحتمل أن تكون مشكلة في SSL. نظراً لأن الواجهة الخلفية مهيأة لاستخدام FQDN، فنحن نعلم أنها ترسل إشارة رقمية (SNI).

    استخدم OPENSSL للتحقق من الشهادة التي يتم إرجاعها. لإجراء هذا الفحص، قم بالاتصال بالواجهة الخلفية باستخدام -servername. يجب أن يعيد SNI، والذي يجب أن يتطابق مع FQDN لمجمع الواجهة الخلفية:

    openssl s_client -connect backendvm.contoso.com:443 -servername backendvm.contoso.com

الطلبات المرسلة إلى المجال المخصص بإرجاع رمز حالة 400

العرض

  • قمت بإنشاء مثيل Azure Front Door. يُرجع طلب النطاق أو مضيف الواجهة الأمامية رمز حالة HTTP 400.
  • قمت بإنشاء تعيين DNS لمجال مخصص لمضيف الواجهة الأمامية الذي قمت بتكوينه. يؤدي إرسال طلب إلى اسم مضيف المجال المخصص إلى إرجاع رمز حالة HTTP 400. لا يبدو أنه يوجه إلى الواجهة الخلفية التي قمت بتكوينها.

السبب

تحدث المشكلة إذا لم تقم بتكوين قاعدة تحويل للمجال المخصص الذي تمت إضافته كمضيف الواجهة الأمامية. يجب إضافة قاعدة التحويل بشكل صريح لمضيف الواجهة الأمامية. تحتاج إلى إنشاء القاعدة حتى إذا تم تكوين قاعدة توجيه بالفعل لمضيف الواجهة الأمامية ضمن المجال الفرعي Azure Front Door، وهو *.azurefd.net.

خطوة استكشاف الأخطاء وإصلاحها

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

لا يُعيد Azure Front Door توجيه HTTP إلى HTTPS

العرض

يحتوي Azure Front Door على قاعدة تحويل تعيد توجيه HTTP إلى HTTPS، ولكن الوصول إلى المجال لا يزال يحافظ على HTTP كبروتوكول.

السبب

يمكن أن يحدث هذا السلوك إذا لم تقم بتكوين قواعد التحويل بشكل صحيح لـ Azure Front Door. التكوين الحالي الخاص بك ليس محدداً وقد يحتوي على قواعد متضاربة.

خطوات استكشاف الأخطاء وإصلاحها

طلب اسم مضيف الواجهة الأمامية يُرجع رمز الحالة 411

العرض

لقد أنشأت مثيل Azure Front Door Standard/Premium وقمت بتكوين:

  • مضيف الواجهة الأمامية.
  • مجموعة أصل بها أصل واحد على الأقل.
  • قاعدة التحويل تربط مضيف الواجهة الأمامية بمجموعة الأصل.

يبدو أن المحتوى غير متوفر عند إرسال طلب إلى مضيف الواجهة الأمامية المكون بسبب إرجاع رمز حالة HTTP 411.

قد تحتوي الردود على هذه الطلبات أيضًا على صفحة خطأ HTML في نص الاستجابة يتضمن بيانًا توضيحيًا. مثال على ذلك الخطأ "HTTP Error 411. The request must be chunked or have a content length."

السبب

هناك العديد من الأسباب المحتملة لهذا العرض. السبب العام هو أن طلب HTTP الخاص بك غير متوافق تمامًا مع RFC.

مثال على عدم الامتثال هو POST طلب تم إرساله دون رأس Content-Length أو Transfer-Encoding. مثال على ذلك هو استخدام curl -X POST https://example-front-door.domain.com. لا يفي هذا الطلب بالمتطلبات المحددة في RFC 7230. سيقوم Azure Front Door بحظره باستجابة HTTP 411. لا يتم تسجيل مثل هذه الطلبات.

هذا السلوك منفصل عن وظيفة جدار حماية تطبيق الويب (WAF) في Azure Front Door. حاليًا، لا توجد طريقة لتعطيل هذا السلوك. يجب أن تفي كافة طلبات HTTP بالمتطلبات حتى إن لم تكن وظيفة WAF قيد الاستخدام.

خطوات استكشاف الأخطاء وإصلاحها

  • تحقق من أن طلباتك تتوافق مع المتطلبات المحددة في RFCs الضرورية.
  • لاحظ أي نص رسالة HTML التي يتم إرجاعها استجابة لطلبك. غالبا ما يشرح نص الرسالة تحديد كيف يكون طلبك غير متوافق.

تم تكوين أصلي كعنوان IP.

العرض

يتم تكوين الأصل كعنوان IP. الأصل سليم، ولكن رفض الطلبات من Azure Front Door.

السبب

مستخدمو Azure Front Door اسم المضيف الأصلي كعنوان SNI أثناء تأكيد اتصال SSL. نظرا لتكوين الأصل كعنوان IP، يمكن أن يكون سبب الفشل أحد الأسباب التالية:

  • يتم تمكين التحقق من اسم الشهادة في تكوين أصل Front Door. من المستحسن ترك هذا الإعداد ممكنا. يتطلب التحقق من اسم الشهادة اسم مضيف الأصل لمطابقة اسم الشهادة أو أحد الإدخالات في ملحق الأسماء البديلة للموضوع.
  • إذا تم تعطيل التحقق من اسم الشهادة، فمن المحتمل أن يكون السبب بسبب منطق شهادة الأصل الذي يرفض أي طلبات ليس لها عنوان مضيف صالح في الطلب الذي يطابق الشهادة.

خطوات استكشاف الأخطاء وإصلاحها

قم بتغيير الأصل من عنوان IP إلى FQDN الذي يتم إصدار شهادة صالحة إليه تطابق شهادة الأصل.

الخطوات التالية