استكشاف أخطاء نقاط نهاية Azure CDN التي ترجع رمز حالة 404 وإصلاحها

هل هذه الصفحة مفيدة؟

هل لديك ملاحظات إضافية؟

سيتم إرسال الملاحظات إلى Microsoft: بالضغط على الزر «إرسال»، سيتم استخدام ملاحظاتك لتحسين منتجات Microsoft وخدماتها. نهج الخصوصية.

تمكنك هذه المقالة من استكشاف مشكلات نقاط نهاية شبكة تسليم محتوى Azure (CDN) التي تعرض رموز حالة استجابة HTTP 404 وإصلاحها.

إذا كنت بحاجة إلى مزيد من المساعدة في أي وقت من هذه المقالة، فيمكنك الاتصال بخبراء Azure على منتديات MSDN Azure وStack Overflow. بدلا من ذلك، يمكنك أيضا تسجيل حادث دعم Azure. انتقل إلى موقع دعم Azure وحدد الحصول على الدعم.

العَرَض

لقد أنشأت ملف تعريف CDN ونقطة نهاية، ولكن لا يبدو أن المحتوى الخاص بك متاح على CDN. يتلقى المستخدمون الذين يحاولون الوصول إلى المحتوى الخاص بك عبر عنوان URL ل CDN رمز حالة HTTP 404.

السبب

هناك العديد من الأسباب المحتملة، بما في ذلك:

• أصل الملف غير مرئي ل CDN.
• تم تكوين نقطة النهاية بشكل خاطئ ، مما يتسبب في ظهور CDN في المكان الخطأ.
• يرفض المضيف رأس المضيف من CDN.
• لم يكن لدى نقطة النهاية الوقت الكافي للانتشار في جميع أنحاء CDN.

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

هام

بعد إنشاء نقطة نهاية CDN ، لن تكون متاحة للاستخدام على الفور ، حيث يستغرق التسجيل وقتا حتى ينتشر من خلال CDN:

• بالنسبة إلى Azure CDN Standard من ملفات تعريف Microsoft، عادة ما يكتمل الانتشار في غضون عشر دقائق.
• بالنسبة إلى Microsoft Azure CDN Standard من ملفات تعريف Akamai، فعادة ما يكتمل الانتشار في خلال دقيقة واحدة.
• بالنسبة إلى Microsoft Azure CDN Standard من ملفات تعريف Verizon، وAzure CDN Premium من Verizon، فعادة ما يكتمل الانتشار في غضون 90 دقيقة.

إذا أكملت الخطوات الواردة في هذا المستند وكنت لا تزال تتلقى 404 ردود، ففكر في الانتظار بضع ساعات للتحقق مرة أخرى قبل فتح تذكرة دعم.

تحقق من الملف الأصلي

أولا ، تحقق من أن الملف المراد تخزينه مؤقتا متاح على الخادم الأصلي ويمكن الوصول إليه بشكل عام على الإنترنت. أسرع طريقة للقيام بذلك هي فتح متصفح في جلسة خاصة أو متخفية والتصفح مباشرة إلى الملف. اكتب عنوان URL أو الصقه في مربع العنوان وتحقق من أنه ينتج عنه الملف الذي تتوقعه. على سبيل المثال، افترض أن لديك ملفا في حساب Azure Storage يمكن الوصول إليه من خلال https://cdndocdemo.blob.core.windows.net/publicblob/lorem.txt. إذا تمكنت من تحميل محتويات هذا الملف بنجاح، فإنه يجتاز الاختبار.

تحذير

على الرغم من أن هذه هي أسرع وأسهل طريقة للتحقق من توفر ملفك للجمهور، إلا أن بعض تكوينات الشبكة في مؤسستك قد تجعل الأمر يبدو وكأن الملف متاح للجمهور عندما يكون مرئيا فقط لمستخدمي شبكتك (حتى إذا تمت استضافته في Azure). للتأكد من أن الأمر ليس كذلك، اختبر الملف باستخدام مستعرض خارجي، مثل جهاز محمول غير متصل بشبكة مؤسستك، أو جهاز ظاهري في Azure.

تحقق من إعدادات الأصل

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

تظهر صفحة الأصل .

نوع الأصل واسم المضيف

تحقق من صحة قيم نوع الأصل واسم مضيف الأصل . في هذا المثال، https://cdndocdemo.blob.core.windows.net/publicblob/lorem.txtيكون جزء اسم المضيف من عنوان URL cdndocdemo.blob.core.windows.net، وهو صحيح. نظرا لأن أصول Azure Storage وWeb App وCloud Service تستخدم قيمة قائمة منسدلة لحقل اسم مضيف Origin ، فإن التهجئة غير الصحيحة ليست مشكلة. ومع ذلك، إذا كنت تستخدم أصلا مخصصا، فتأكد من كتابة اسم المضيف بشكل صحيح.

منافذ HTTP و HTTPS

تحقق من منافذ HTTPوHTTPS. في معظم الحالات ، يكون 80 و 443 صحيحين ، ولن تحتاج إلى أي تغييرات. ومع ذلك ، إذا كان الخادم الأصلي يستمع إلى منفذ مختلف ، فستحتاج إلى تمثيله هنا. إذا لم تكن متأكدا، يمكنك عرض عنوان URL لملفك الأصلي. تستخدم مواصفات HTTP وHTTPS المنفذين 80 و443 كافتراضيين. في مثال عنوان URL ، https://cdndocdemo.blob.core.windows.net/publicblob/lorem.txtلم يتم تحديد منفذ ، لذلك يتم افتراض الإعداد الافتراضي ل 443 والإعدادات صحيحة.

ومع ذلك، افترض أن عنوان URL للملف الأصلي الذي اختبرته سابقا هو http://www.contoso.com:8080/file.txt. لاحظ الجزء :8080 في نهاية مقطع اسم المضيف. يرشد هذا الرقم المتصفح إلى استخدام المنفذ 8080 للاتصال بخادم الويب في www.contoso.com ، لذلك ستحتاج إلى إدخال 8080 في حقل منفذ HTTP . من المهم ملاحظة أن إعدادات المنفذ هذه تؤثر فقط على المنفذ الذي تستخدمه نقطة النهاية لاسترداد المعلومات من الأصل.

ملاحظة

لا يسمح Azure CDN Standard من نقاط نهاية Akamai بنطاق منفذ TCP الكامل للأصول. للحصول على قائمة بمنافذ المنشأ غير المسموح بها، راجع Azure CDN من منافذ Akamai الأصلية المسموح بها.

تحقق من إعدادات نقطة النهاية

في صفحة نقطة النهاية ، حدد الزر تكوين .

تظهر صفحة تكوين نقطة نهاية CDN.

البروتوكولات

بالنسبة للبروتوكولات، تحقق من تحديد البروتوكول الذي يستخدمه العملاء. نظرا لأن نفس البروتوكول الذي يستخدمه العميل هو البروتوكول المستخدم للوصول إلى الأصل، فمن المهم تكوين منافذ الأصل بشكل صحيح في القسم السابق. تستمع نقطة نهاية CDN فقط إلى منافذ HTTP وHTTPS الافتراضية (80 و443)، بغض النظر عن منافذ الأصل.

دعونا نعود إلى مثالنا الافتراضي مع http://www.contoso.com:8080/file.txt. كما ستتذكر ، حدد Contoso 8080 كمنفذ HTTP الخاص بهم ، ولكن لنفترض أيضا أنهم حددوا 44300 كمنفذ HTTPS الخاص بهم. إذا قاموا بإنشاء نقطة نهاية باسم contoso ، فسيكون اسم مضيف نقطة نهاية CDN الخاص بهم contoso.azureedge.net. طلب http://contoso.azureedge.net/file.txt HTTP هو طلب HTTP ، لذلك ستستخدم نقطة النهاية HTTP على المنفذ 8080 لاسترداده من الأصل. سيؤدي الطلب الآمن عبر HTTPS إلى استخدام نقطة النهاية ل HTTPS https://contoso.azureedge.net/file.txtعلى المنفذ 44300 عند استرداد الملف من الأصل.

عنوان المضيف الأصل

رأس مضيف الأصل هو قيمة رأس المضيف المرسلة إلى الأصل مع كل طلب. في معظم الحالات ، يجب أن يكون هذا هو نفس اسم مضيف Origin الذي تحققنا منه سابقا. لن تتسبب القيمة غير الصحيحة في هذا الحقل بشكل عام في حالات 404، ولكن من المحتمل أن تتسبب في حالات 4xx أخرى، اعتمادا على ما يتوقعه الأصل.

مسار الأصل

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

في نقطة النهاية على سبيل المثال، أردنا أن تكون جميع الموارد الموجودة على حساب التخزين متاحة، لذلك تم ترك مسار Origin فارغا. هذا يعني أن طلب النتائج https://cdndocdemo.azureedge.net/publicblob/lorem.txt في اتصال من نقطة النهاية إلى cdndocdemo.core.windows.net التي تطلب / publicblob/lorem.txt. وبالمثل ، فإن طلب https://cdndocdemo.azureedge.net/donotcache/status.png النتائج في نقطة النهاية التي تطلب / donotcache / status.png من الأصل.

ولكن ماذا لو كنت لا ترغب في استخدام CDN لكل مسار على أصلك؟ لنفترض أنك أردت فقط فضح مسار publicblob . إذا أدخلنا /publicblob في حقل مسار المنشأ، سيؤدي ذلك إلى إدراج نقطة النهاية /publicblob قبل كل طلب يتم تقديمه إلى الأصل. هذا يعني أن طلب الحصول على https://cdndocdemo.azureedge.net/publicblob/lorem.txt سيأخذ الآن بالفعل جزء الطلب من عنوان URL ، /publicblob / lorem.txt، وإلحاق /publicblob بالبداية. ينتج عن ذلك طلب /publicblob/ publicblob/lorem.txt من الأصل. إذا لم يتم حل هذا المسار إلى ملف فعلي، فسيرجع الأصل حالة 404. عنوان URL الصحيح لاسترداد lorem.txt في هذا المثال سيكون في الواقع https://cdndocdemo.azureedge.net/lorem.txt. لاحظ أننا لا نقوم بتضمين مسار /publicblob على الإطلاق، لأن جزء الطلب من عنوان URL هو /lorem.txt وتضيف نقطة النهاية /publicblob، مما يؤدي إلى أن يكون /publicblob/lorem.txt هو الطلب الذي تم تمريره إلى الأصل.