استكشاف وإصلاح خطأ HTTP 404 غير موجود على IIS - دليل لمديري النظام

قم بتمكين الأخطاء التفصيلية في IIS وخذ الـ URL المطلوب بالضبط، ثم قارنه مع روابط الموقع لتحديد أي موقع أو vdir هو المقصود. هذا الإجراء الأول غالباً ما يكشف عما إذا كان المورد مفقوداً، أو ضائعاً، أو موجوداً في موقع مختلف عبر بنيتك التحتية، مما يساعدك على تحديد مالك التعيين والمسار الصحيح بسرعة.

حدد ما إذا كان الـ 404 ناتجاً عن ملف مفقود، أو دليل افتراضي غير مُهيأ بشكل صحيح، أو إعادة توجيه تشير إلى موقع غير موجود. في مدير IIS، افحص إعدادات vdir وتحقق من المسار الفعلي على القرص، ثم تحقق من الأذونات على المجلد حتى يتمكن عملية العمل من الاستمرار عبر المواقع المختلفة. إذا كان لديك عدة مواقع، قم بسرد مجلدات الجذر الخاصة بها والمواقع التي تخدمها لمنع الالتباس بين المواقع.

بالنسبة لتطبيقات الويب التي تستخدم روابط دائمة، تأكد من أن قواعد إعادة كتابة URL أو تعيينات المعالج لا تخفي 404 حقيقياً بصفحة ودية. قم بتحديث web.config أو قواعد إعادة كتابة URL، ثم اختبر مسار الإنترنت من متصفح ومن سجلات الخادم للتأكيد على أن الـ URL الناتج يحل إلى ملف حقيقي أو مسار صالح.

إذا لم يكن المورد موجوداً، قم بإنشاء حامل مكان أو نقل الملف إلى الموقع المقصود، أو قم بتكوين مسار ثابت/ASP.NET مناسب لتقديم المورد. بالنسبة لكل موقع، احتفظ بسجل للـ مالك وموقع المحتوى المقصود لتسريع التحديدات المستقبلية. استخدم الروابط الدائمة للتحقق من أن الـ URLs القانونية ترتبط بموارد موجودة، مما يقلل من 404s المفقودة المستقبلية.

ثم استمر في التحقق المنهجي: تحقق من الـ URL المواجه للإنترنت، تأكد من أن DNS وعناوين المضيف تشير إلى الموقع الصحيح، وربط الروابط الدائمة بمسار ملف حقيقي. إذا كنت لا تزال ترى 404، تتبع الطلب من سجل طلبات IIS، حدد أين يضيع المسار، واضبط وفقاً لذلك، وسجل التغييرات للمالك والفريق.

تحليل سجلات IIS لأنماط 404 وURLs الفاشلة

قم بتصدير أحدث سجلات IIS وتصفيتها لاستجابات 404. ابحث عن مسارات URL المتكررة وطابع الوقت الأول لتحديد المشكلات المتكررة التي تؤثر على الأشخاص الذين يحاولون الوصول إلى موقعك.

تكشف الأنماط في 404s عن الأسباب الشائعة: موارد مفقودة، إدخالات vdir غير مُهيأة بشكل صحيح، وخطأ إملائي في رابط. تنشأ بعض المشكلات من المحتوى المعاد توجيهه أو النقل، بينما تأتي أخرى من التنقل الداخلي أو الإشارات الخارجية. سجل قيمة vdir في ملاحظاتك للحفاظ على الفهارسة متسقة. قم ببناء قائمة بالمخالفين الرئيسيين وتتبع العدد مع مرور الوقت لتمييز الإخفاقات العرضية عن المشكلات المتكررة بانتظام.

استخدم حقول المرجع والوكيل المستخدم لتقييم ما إذا كانت المشكلة تأتي من البحث، أو مواقع أخرى، أو عمليات بحث مباشرة. هذا يساعدك على تحديد أولويات حل السبب الجذري وتحسين تجربة المستخدم مع أقل احتكاك.

قم بتصدير عرض متوافق مع الجدول لـ 404s، بما في ذلك مسار URL، العدد، الأول رؤية، المرجع، والملاحظات. يدعم هذا التنسيق الصديق للطباعة تحديث أصحاب المصلحة والحفاظ على مصدر وحيد للحقيقة لتحسين المسارات والفهارسة.

مسار URL	الحالة	العدد	الأول رؤية	المرجع	الملاحظات
/images/logo.png	404	120	2025-11-01 08:23:11	https://example.com/home	ملف مفقود على القرص
/docs/guide.html	404	68	2025-11-02 09:12:05	https://example.com/manuals	نُقل إلى /docs/user-guide.html؛ قم بتحديث الروابط
/shop/vdir/index.html	404	42	2025-11-03 11:01:22	https://example.com/shop/	تكوين VDir خاطئ؛ تحقق من المسار

إجراءات لحل ومنع 404s

بالنسبة للموارد المفقودة، أعد الملف أو أنشئ إعادة توجيه 301 إلى الـ URL الصحيح. بالنسبة لـ vdirs غير المُهيأة، تحقق من مسار vdir في مدير IIS، تحقق من applicationHost.config، وتأكد من وجود مسار فيزيائي موجود. بالنسبة للأخطاء الإملائية، أصلح الرابط، قم بتحديث المحتوى حول الصفحة، وأعد تحديث فهارس البحث الداخلية بانتظام.

اطبع تقريراً موجزاً وشاركه مع فريق الدعم. استمر في تحديث قائمة جارية بالتغييرات لتتبع ما نجح وما لم ينجح. بالنسبة لعدة مخالفين متكررين، قم بتنفيذ إعادة توجيه مستهدفة وإزالة الروابط الميتة لتقليل الأخطاء المستقبلية.

راجع الأنماط التي تجمعها بانتظام، مما يحسن التعامل مع 404s، واختبر إعادة التوجيه في بيئة الاختبار قبل تطبيق التحديثات على الإنتاج. يقلل هذا النهج من الأخطاء ويساعد الأشخاص على الحصول على تجربة أكثر سلاسة عند التنقل في موقعك.

التحقق من روابط الموقع، وعناوين المضيف، والدلائل الافتراضية

راجع وأصلح الروابط فوراً: تأكد من أن رأس المضيف، وعنوان IP، والمنفذ يتطابقان مع طلب العميل وأن اسم الموقع يتوافق مع الـ URL المستخدم.

فحوصات الربط

• افتح مدير IIS، انتقل إلى Sites > [موقعك] > Bindings. تحقق من وجود ربط لـ http (وhttps إذا تم استخدامه) مع عنوان IP والمنفذ الصحيحين. إذا كانت عدة مواقع تشارك نفس IP:port، أضف قيمة اسم المضيف (رأس المضيف) التي تتطابق مع الـ URL الحالي لتوجيه الطلبات بشكل صحيح.

• اختبر الطلبات برأس المضيف الدقيق: curl -I -H "Host: example.com" http://server/ أو استخدم متصفح. إذا استمر 404، قد يكون الربط صحيحاً لكن المسار المطلوب يتم التعامل معه بواسطة موقع آخر.

• بالنسبة لـ https، تحقق من أن الشهادة تتطابق مع اسم المضيف في الربط. تحقق من الموضوع وSANs، وتأكد من أن الربط يستخدم الشهادة الصحيحة على المنفذ 443. يمكن أن يؤدي عدم التطابق إلى فشل الطلبات التي تبدو كموارد مفقودة.

• افحص طبقات DNS والوكيل: تأكد من أن الطلب الوارد يحمل رأس المضيف المتوقع؛ يمكن أن يؤدي تكوين وكيل خاطئ إلى هبوط الطلبات على الموقع الخاطئ، مما يؤدي إلى 404s لمسارات صالحة.

الدلائل الافتراضية وتكوين المسار

1. تحقق من وجود اسم مستعار الدليل الافتراضي تحت الموقع؛ يجب أن يظهر الاسم المستعار كقطعة URL (على سبيل المثال /files). راجع المسار الفيزيائي في اللوحة اليمنى وتأكد من وجود المجلد وأنه يمكن الوصول إليه بواسطة هوية تجمع التطبيقات.

2. حول إلى تطبيق عندما يجب أن يشغل الدليل كوداً. انقر بزر الفأرة الأيمن على الدليل الافتراضي > Convert to Application، حدد تجمع التطبيقات الصحيح، وتأكد من أن هوية التجمع لديها أذونات قراءة للمسار الفيزيائي.

3. تحقق من الوثائق الافتراضية إذا كنت تعتمد على URLs على مستوى الدليل؛ تأكد من وجود وثيقة افتراضية صالحة (index.html، default.aspx، إلخ) أو قدم مسار ملف صريح في روابطك.

4. راجع قواعد web.config وإعادة كتابة URL التي قد تعيد التوجيه إلى مسار غير موجود. يمكن أن تنتج قاعدة سيئة 404 لمورد مفقود لصفحات صالحة أخرى؛ اضبط أو أزل القواعد المتعارضة.

5. تحقق من الأذونات: منح القراءة/التنفيذ إلى IIS_IUSRS وهوية تجمع التطبيقات على المسار الفيزيائي، وتحقق من ACLs NTFS تسمح بالوصول للمستخدم المتوقع. غالباً ما تسبب الأذونات المفقودة 404s التي تبدو كأن المحتوى قد ذهب.

6. اختبر مرة أخرى بعد التغييرات: اطلب الـ URL المشكل وتأكد من 200 أو إعادة توجيه مناسبة؛ إذا حدث حلقة إعادة توجيه أو بقي المورد مفقوداً، راجع قواعد إعادة الكتابة وسجلات بدء التشغيل في تجمع التطبيقات.

استخدم زحفاً أساسياً لاكتشاف المشكلة الحالية حول الصفحات المفقودة الناتجة عن الروابط أو الدلائل الافتراضية. قم بـ grep عبر سجلات IIS لإدخالات 404 للعثور على الطلبات الفاشلة، ثم معالجة السبب الجذري واختبر مرة أخرى في زحف جديد. احفظ النتائج وشارك ملخصاً موجزاً مع المسؤولين والزملاء على linkedin للحفاظ على التوافق بين الجميع أثناء التعامل مع المشكلة.

التحقق من مسارات الملفات، الوجود الفيزيائي، وأذونات الملف

تحقق من المسار الفيزيائي للموقع في مدير IIS وتأكد من وجود المسار على القرص. في الإعدادات الأساسية للموقع أو الدليل الافتراضي، تأكد من أن المجلد الذي تشير إليه يحتوي على المحتوى المتوقع. إذا تغير المسار، أعد الموقع الأصلي أو أصلح التعيين في الـ snap-in حتى تتوجه الطلبات إلى المجلد الصحيح؛ وإلا سيحمل IIS لا شيء وسترى 404s.

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

تحقق من تعيين نوع MIME للامتدادات التي تقدمها. افتح نوع MIME للموقع وتأكد من أن الامتداد لديه نوع MIME مرتبط؛ غالباً ما تؤدي التعيينات المفقودة إلى 404. إذا لزم الأمر، أضف أنواع شائعة (.html، .css، .js، الصور، الخطوط) وتحقق من إرسال النوع المحتوى الصحيح. كما تحقق من تحميل URLs الروابط الدائمة من المجلد الصحيح؛ يمكن أن يؤدي عدم التطابق بين مسار الرابط الدائم والمسار الفيزيائي إلى إثارة 404 لكل من الأصول الثابتة والديناميكية.

راجع إعدادات تفويض طلبات الموقع. في الـ snap-in، انتقل إلى قواعد التفويض للموقع وتأكد من أن هوية العميل مسموح لها بقراءة المجلد المطلوب. إذا حظرت قاعدة رفض الملف، قد يعيد المحرك 404 لبعض المسارات؛ إزالة القاعدة أو تضييقها يساعد. تأكد من تمكين المصادقة المجهولة إذا كنت تعتمد على الوصول العام، وتحقق من الإعدادات على مستوى النطاق أو الموقع إذا كانت عدة مواقع تشارك نفس جذر المحتوى.

قم بتمكين وفحص السجلات والتتبع. قم بتشغيل تتبع الطلبات الفاشلة لأخطاء 404 أو راجع سجلات IIS لتحديد عدد الضربات وعنوان الطلب. ابحث عن الـ URL الدقيق، والمسار المُعيَّن، ومسار الملف من المحرك؛ تساعد هذه البيانات المحددة في تحديد المصدر. استخدم المعلومات لاستعادة مسار صحيح، إصلاح ترتيب التحميل، ومنع التكرارات المزعجة. على المواقع المواجهة للإنترنت، تحقق من أن ملفات تعريف النطاق والمسار الفيزيائي يتوافقان؛ يمكن أن يؤدي عدم تطابق صغير إلى كسر الوصول لعدة مواقع. بعد التغييرات، أعد تدوير تجمع التطبيقات لتطبيق التعيينات والأذونات الجديدة. إذا كنت تعالج 404 باستمرار، عالج السبب الجذري أولاً ثم تحقق من رحلة المستخدم عبر جميع المواقع.

مراجعة قواعد إعادة كتابة URL وتكوينات الأخطاء المخصصة

قم بتصدير قواعد إعادة كتابة URL الحالية من IIS لكل موقع وقارنها بأساس جيد معروف لتحديد التكوينات الخاطئة التي تؤدي إلى نتائج 404. سيكشف هذا عما إذا كانت المشكلة تنشأ من URL مُعاد كتابته، أو مورد مفقود، أو مسار خطأ مخصص غير مناسب.

ما يجب فحصه

حدد القواعد في web.config أو عبر وحدة إعادة كتابة URL لكل موقع. راجع النمط والشروط التي تثير إعادة الكتابة أو التوجيه، وتحقق من أن الـ URL المستهدف يشير إلى مورد موجود أو صفحة html مناسبة مُعرَّفة في الأخطاء المخصصة. تأكد من أن إدخال 404 مُعرَّف وأن المسار المستخدم بواسطة صفحة الخطأ موجود تحت جذر الموقع. تحقق من التعارضات بين المواقع التي تشارك تجمع تطبيقات واحد يعيِّن نفس المسارات.

راجع ترتيب التقييم: تتوقف القاعدة المطابقة الأولى عن المعالجة الإضافية. ابحث عن قواعد واردة أو صادرة قد تلتقط 404 قبل تشغيل معالج الخطأ المخصص، وتأكد من وجود صفحة 404 احتياطية في الموقع المُهيَّأ. راجع أي إعدادات عامة أو على مستوى الموقع قد تتجاوز التكوين على مستوى الموقع.

كيفية تطبيق الإصلاحات

إذا كانت قاعدة مُهيَّأة بشكل خاطئ، اضبط نمط التطابق، وإجراء إعادة الكتابة، والوجهة. تأكد من أن مورداً مفقوداً لا يُعاد كتابته إلى مسار موجود يعيد استجابة غير 404. قم بتحديث قسم الأخطاء المخصصة حتى تتوجه طلبات 404 إلى ملف html حقيقي وتحقق من نشر الملف بأذونات صحيحة. بعد التغييرات، أعد تدوير تجمع التطبيقات واختبر من بيئات عميل مختلفة للتأكيد على النتائج المتسقة. استخدم سجلات الخادم وبيانات تتبع الطلبات الفاشلة (FRT) لتحديد القاعدة الدقيقة وصفحة الاستجابة النهائية.

إعادة إنتاج الفشل باختبارات مستهدفة ورصد الاستجابات

التوصية: أعد إنتاج الـ 404 باختبارات مستهدفة ورصد الاستجابات في لوحة تحكم مشتركة. التقط الأدلة في accesslog وحدد مالكاً لكل نمط لتسريع الإصلاح. يساعد هذا النهج الإدارة على رؤية التأثير الحالي وتحديد أولويات الإصلاحات عبر نطاقات الموقع.

قم بتصدير آخر 200 إدخال 404 من accesslog للموقع. بالنسبة لكل إدخال، سجل الوقت، وعنوان IP للعميل، واسم المضيف، والـ URL المطلوب، والمرجع، ووكيل المستخدم، والحالة، وحجم الاستجابة. إذا لاحظت أصولاً مفقودة تحت مسارات ذات صلة، فهذا يشير إلى أنماط بدلاً من حالات معزولة. قم ببناء قائمة اختبار موجزة من هذه الإشارات لاتخاذ الخطوات التالية.

اختبر تنويعات المسارات: اطلب URLs معروفة مفقودة مع ودون شريطة نهاية؛ غير حالة الأجزاء؛ أضف أو أزل سلاسل الاستعلام؛ قارن الاستجابات للأصول الثابتة مقابل المسارات الديناميكية. قم بتضمين كل من طرق GET وHEAD للتأكيد على أن الخادم يعيد 404 قبل أي إعادة توجيه أو إعادة كتابة غير مقصودة.

استخدم تتبع الطلبات الفاشلة (FRT) عند التوفر، وقارن مع accesslog لنفس الطوابع الزمنية. تشير هذه التتبعات إلى القاعدة أو الوحدة التي حظرت المورد، أو إذا كان المورد مفقوداً حقاً. ربط النتائج بمقياس لوحة التحكم: عدد 404s حسب المسار، حسب المضيف، وحسب الحساب. تسرع هذه الارتباط الجيد التحقيق وتكشف النقاط الساخنة الحالية.

بالنسبة للموارد خلف طبقة إعادة كتابة أو توجيه، تحقق من web.config ذات الصلة، وقواعد إعادة كتابة URL، وأي تكوينات مشابهة لـ htaccess التي قد يحترمها IIS عبر وحدات إعادة الكتابة. إذا أشار الـ 404 إلى مشكلة تعيين، اضبط القاعدة أو مسار الملف، ثم أعد تشغيل الاختبارات للتأكيد على الإصلاح قبل الانتقال إلى الإنتاج. في الحالات التي يشير فيها الـ 404 إلى مورد محظور، تحقق من قائمة الحظر أو قيود الوصول وتأكد من توافقها مع أنماط الوصول المقصودة.

سجل النتائج في لوحة التحكم وشارك الملخص مع مالك الموقع والإدارة. إذا لزم الأمر، انشر الرؤى على linkedin للرؤية عبر الفرق. يجب أن يكون العملية قابلة للتكرار: احفظ مدخلات الاختبار، التقط الاستجابات، وربط السجلات ذات الصلة من accesslog حتى يتمكن مالك الحساب أو فريق الأمان من مراجعتها.

طرق لتحسين المرونة: قم ببناء حارس اختبار صغير يتكرر عبر قائمة الاختبار، يسجل رموز الحالة، ويحدد الارتفاعات. استخدم هذه الإشارات لاتخاذ إجراء بشأن الأصول المفقودة، تحديث جرد المحتوى، وحظر الاستكشافات الصاخبة بواسطة IP فقط عند الضرورة. احرص دائماً على توافق مجموعة الاختبار الحالية مع جرد الموقع وتعيينات نوع MIME لمنع التراجعات.

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