Устранение ошибок HTTP 404 Not Found в IIS – Руководство для системного администратора

Включите подробные ошибки в IIS и возьмите точный запрошенный URL-адрес, затем сравните его с привязками сайта, чтобы определить, какой сайт или виртуальный каталог (vdir) предполагается использовать. Это первое действие часто показывает, отсутствует ли ресурс, потерян или находится в другом месте вашей инфраструктуры, помогая вам быстро найти владельца сопоставления и правильный путь.

Определите, является ли ошибка 404 результатом отсутствующего файла, неправильно настроенного виртуального каталога или перенаправления, указывающего на несуществующее местоположение. В диспетчере IIS проверьте настройки vdir и убедитесь в физическом пути на диске, затем проверьте разрешения для папки, чтобы рабочий процесс мог продолжаться на разных сайтах. Если у вас несколько сайтов, перечислите их корневые папки и местоположения, которые они обслуживают, чтобы предотвратить путаницу между сайтами.

Для веб-приложений, использующих постоянные ссылки (permalinks), убедитесь, что правила перезаписи URL-адресов или сопоставления обработчиков не маскируют реальную ошибку 404 дружественной страницей. Обновите правила web.config или перезаписи URL-адресов, затем протестируйте интернет-путь из браузера и из серверных журналов, чтобы подтвердить, что полученный URL-адрес разрешается в фактический файл или допустимый маршрут.

Если ресурс отсутствует, создайте заполнитель или переместите файл в нужное место, либо настройте правильный статический/ASP.NET маршрут для обслуживания ресурса. Для каждого сайта ведите запись об владельце и предполагаемом местоположении контента, чтобы ускорить идентификацию в будущем. Используйте постоянные ссылки, чтобы убедиться, что канонические URL-адреса соответствуют существующим ресурсам, уменьшая количество будущих потерянных 404 ошибок.

Затем продолжите систематическую проверку: проверьте URL-адрес, обращенный к Интернету, убедитесь, что DNS и заголовки хоста указывают на правильный сайт, и сопоставьте постоянные ссылки с реальным файловым путем. Если вы все еще видите ошибку 404, проследите за запросом из журнала запросов IIS, определив, где путь потерян, и внесите соответствующие изменения, документируя изменения для владельца и команды.

Анализируйте журналы IIS на предмет закономерностей ошибок 404 и неудачных URL-адресов

Экспортируйте последние журналы IIS и отфильтруйте ответы 404. Ищите частые URL-пути и первую замеченную временную метку, чтобы точно определить повторяющиеся проблемы, влияющие на людей, пытающихся получить доступ к вашему сайту.

Закономерности в ошибках 404 выявляют общие причины: отсутствующие ресурсы, неправильно настроенные записи vdir и опечатки в ссылке. Некоторые проблемы возникают из перенаправленного или перемещенного контента, в то время как другие происходят из внутренней навигации или внешних ссылок. Запишите значение vdir в своих заметках, чтобы обеспечить согласованность индексации. Составьте список основных нарушителей и отслеживайте количество обращений с течением времени, чтобы отличать случайные пропуски от регулярно повторяющихся проблем.

Используйте поля referrer и user-agent, чтобы оценить, возникает ли проблема из поиска, других сайтов или прямых поисков. Это поможет вам расставить приоритеты при устранении основной причины и улучшить пользовательский опыт с меньшим количеством проблем.

Экспортируйте удобное для табличного представления представление ошибок 404, включая URL-путь, количество, первое появление, referrer и заметки. Этот удобный для печати формат поддерживает обновление заинтересованных сторон и поддержание единого источника достоверной информации для оптимизации путей и индексации.

Действия по устранению и предотвращению ошибок 404

Для отсутствующих ресурсов восстановите файл или создайте перенаправление 301 на правильный URL-адрес. Для неправильно настроенных vdirs проверьте путь vdir в диспетчере IIS, проверьте applicationHost.config и убедитесь в наличии физического пути. Для опечаток исправьте ссылку, обновите контент о странице и регулярно обновляйте внутренние поисковые индексы.

Распечатайте сводный отчет и поделитесь им со службой поддержки. Продолжайте обновлять текущий список изменений, чтобы отслеживать, что сработало, а что нет. Для нескольких частых нарушителей реализуйте целевые перенаправления и удалите мертвые ссылки, чтобы уменьшить количество будущих ошибок.

Регулярно просматривайте собранные вами шаблоны, оптимизируя обработку ошибок 404, и тестируйте перенаправления в промежуточной среде, прежде чем применять обновления в рабочей среде. Этот подход сводит к минимуму ошибки и помогает людям получать больше удовольствия при навигации по вашему сайту.

Проверьте привязки сайта, заголовки хоста и виртуальные каталоги

Немедленно просмотрите и исправьте привязки: убедитесь, что заголовок хоста, IP и порт соответствуют запросу клиента и что имя сайта соответствует используемому URL-адресу.

Проверки привязки

• Откройте диспетчер IIS, перейдите в Сайты > [ваш сайт] > Привязки. Убедитесь, что есть привязка для http (и https, если используется) с правильным IP-адресом и портом. Если несколько сайтов используют один и тот же IP:порт, добавьте значение имени хоста (заголовок хоста), которое соответствует текущему URL-адресу, чтобы правильно маршрутизировать запросы.
• Проверьте запросы с точным заголовком хоста: curl -I -H "Host: example.com" http://server/ или используйте браузер. Если ошибка 404 сохраняется, привязка может быть правильной, но запрошенный путь обрабатывается другим сайтом.
• Для https убедитесь, что сертификат соответствует имени хоста в привязке. Проверьте субъект и SAN и убедитесь, что привязка использует правильный сертификат на порту 443. Несоответствие может привести к неудачным запросам, которые выглядят как отсутствующие ресурсы.
• Проверьте DNS и прокси-уровни: убедитесь, что входящий запрос содержит ожидаемый заголовок хоста; неправильная конфигурация прокси-сервера может привести к тому, что запросы попадут на неправильный сайт, что приведет к ошибкам 404 для допустимых путей.

Виртуальные каталоги и конфигурация пути

1. Убедитесь, что псевдоним виртуального каталога существует на сайте; псевдоним должен отображаться как сегмент URL-адреса (например, /files). Просмотрите физический путь в правой панели и убедитесь, что папка существует и доступна для удостоверения пула приложений.
2. Преобразуйте в Приложение, когда каталог должен выполнять код. Щелкните правой кнопкой мыши виртуальный каталог > Преобразовать в приложение, выберите правильный пул приложений и убедитесь, что удостоверению пула приложений предоставлены разрешения на чтение для физического пути.
3. Проверьте документы по умолчанию, если вы полагаетесь на URL-адреса уровня каталога; убедитесь, что есть допустимый документ по умолчанию (index.html, default.aspx и т. д.) или укажите явный путь к файлу в ваших ссылках.
4. Просмотрите правила web.config и правила перезаписи URL-адресов, которые могут перенаправлять в несуществующий путь. Неправильное правило может привести к ошибке 404 отсутствующего ресурса для страниц, которые в противном случае были бы действительными; настройте или удалите конфликтующие правила.
5. Проверьте разрешения: предоставьте разрешения на чтение/выполнение для IIS_IUSRS и удостоверения пула приложений для физического пути и убедитесь, что списки ACL NTFS разрешают доступ для ожидаемого пользователя. Отсутствующие разрешения часто вызывают ошибки 404, которые выглядят так, как будто контент исчез.
6. Проверьте снова после изменений: запросите проблемный URL-адрес и подтвердите ответ 200 или соответствующее перенаправление; если перенаправление зацикливается или ресурс остается отсутствующим, просмотрите правила перезаписи и журналы запуска в пуле приложений.

Используйте базовый обход, чтобы обнаружить текущую проблему с отсутствующими страницами, вызванную привязками или виртуальными каталогами. grep через журналы IIS для записей 404, чтобы найти, какие запросы не удаются, затем устраните основную причину и повторите тестирование в новом обходе. Сохраните результаты и поделитесь кратким обзором с администраторами и коллегами в LinkedIn, чтобы поддерживать согласованность всех во время решения проблемы.

Проверьте пути к файлам, физическое существование и разрешения на доступ к файлам

Убедитесь, что физический путь сайта в диспетчере IIS существует на диске. В Basic Settings для сайта или виртуального каталога убедитесь, что папка, на которую вы указываете, содержит ожидаемый контент. Если путь изменился, восстановите исходное местоположение или исправьте сопоставление в оснастке, чтобы запросы адресовались к правильной папке; в противном случае IIS ничего не загружает, и вы видите ошибки 404.

Убедитесь, что файл фактически существует в файловой системе и что удостоверение пула приложений имеет права на перемещение по нему и чтение его. Используйте проводник или icacls для проверки списков ACL в папке и всех родительских папках. Предоставьте разрешения Read и List Folder Contents и Traverse удостоверению пула приложений (например, IIS APPPOOLYourAppPool) в корне контента и файлах внутри него. Если разрешения неверны, IIS указывает на отказ в доступе, и движок может вернуть ошибку 404, даже если файл существует. Соответствующим образом настройте списки ACL и повторите тестирование. Если вы не уверены, временно назначьте доступ на чтение известному пользователю, чтобы подтвердить загрузку файла.

Проверьте сопоставление типов MIME для расширений, которые вы обслуживаете. Откройте тип MIME для сайта и убедитесь, что расширение имеет связанный тип MIME; отсутствующие сопоставления часто приводят к ошибке 404. При необходимости добавьте общие типы (.html, .css, .js, изображения, шрифты) и убедитесь, что отправляется правильный content-type. Также убедитесь, что URL-адреса в стиле постоянных ссылок загружаются из правильной папки; несоответствие между маршрутом постоянной ссылки и физическим путем может вызвать ошибку 404 как для статических, так и для динамических активов.

Просмотрите настройки авторизации запросов сайта. В оснастке перейдите к Правилам авторизации сайта и убедитесь, что удостоверению клиента разрешено читать запрошенную папку. Если правило запрета блокирует файл, движок может вернуть ошибку 404 для некоторых путей; удаление правила или его сужение помогает. Убедитесь, что анонимная аутентификация включена, если вы полагаетесь на общий доступ, и проверьте настройки на уровне домена или сайта, если несколько сайтов используют один и тот же корень контента.

Включите и проверьте журналы и трассировку. Включите трассировку неудачных запросов для ошибок 404 или просмотрите журналы IIS, чтобы определить количество хитов и запрашивающий адрес. Найдите точный URL-адрес, сопоставленный путь и путь к файлу из движка; эти идентифицирующие данные помогают найти источник. Используйте информацию для восстановления правильного пути, исправления порядка загрузки и предотвращения неприятных повторений. На сайтах, обращенных к Интернету, убедитесь, что профили домена и физический путь совпадают; небольшое несоответствие может нарушить доступ для нескольких сайтов. После изменений перезапустите пул приложений, чтобы применить новые сопоставления и разрешения. Если вы последовательно устраняете ошибку 404, сначала устраните основную причину, а затем проверьте путь пользователя на всех сайтах.

Просмотрите правила перезаписи URL-адресов и конфигурации пользовательских ошибок

Экспортируйте текущие правила перезаписи URL-адресов из IIS для каждого сайта и сравните их с известной хорошей базовой линией, чтобы точно определить неправильные конфигурации, приводящие к результатам 404. Это покажет, возникает ли проблема в перезаписанном URL-адресе, отсутствующем ресурсе или неправильном пути к пользовательской ошибке.

Что следует проверить

Найдите правила в web.config или через модуль перезаписи URL-адресов для каждого сайта. Просмотрите шаблон и условия, которые запускают перезапись или перенаправление, и убедитесь, что целевой URL-адрес указывает на существующий ресурс или правильную HTML-страницу, определенную в Custom Errors. Убедитесь, что определена запись 404 и что путь, используемый страницей ошибок, существует в корне сайта. Проверьте наличие конфликтов между сайтами, использующими один пул приложений, которые сопоставляют одни и те же пути.

Проверьте порядок оценки: первое совпадающее правило прекращает дальнейшую обработку. Найдите входящие или исходящие правила, которые могут перехватить ошибку 404 до запуска обработчика пользовательских ошибок, и убедитесь, что в настроенном месте есть резервная страница 404. Просмотрите любые глобальные или уровневые настройки сайта, которые могут переопределить конфигурацию для каждого сайта.

Как применять исправления

Если правило настроено неправильно, настройте шаблон соответствия, действие перезаписи и назначение. Убедитесь, что отсутствующий ресурс не перезаписывается в существующий путь, который возвращает ответ, отличный от 404. Обновите раздел Custom Errors, чтобы запросы 404 направлялись в реальный HTML-файл, и убедитесь, что файл развернут с правильными разрешениями. После изменений перезапустите пул приложений и протестируйте из разных клиентских сред, чтобы подтвердить согласованные результаты. Используйте журналы сервера и данные трассировки неудачных запросов (FRT), чтобы идентифицировать точное правило и окончательную страницу ответа.

Воспроизводите сбои с помощью целевых тестов и отслеживайте ответы

Рекомендация: Воспроизведите ошибку 404 с помощью целевых тестов и отслеживайте ответы на общей панели управления. Запишите доказательства в accesslog и назначьте владельца для каждого шаблона, чтобы ускорить исправление. Такой подход помогает руководству увидеть текущее влияние и определить приоритеты исправлений в разных областях сайта.

Экспортируйте последние 200 записей 404 из accesslog для сайта. Для каждой записи запишите время, IP-адрес клиента, имя хоста, запрошенный URL-адрес, реферер, user-agent, статус и размер ответа. Если вы наблюдаете отсутствующие ресурсы в связанных путях, это указывает на закономерности, а не на изолированные случаи. Создайте краткий список тестов из этих сигналов, чтобы предпринять следующие шаги.

Протестируйте вариации путей: запросите известные отсутствующие URL-адреса с и без завершающего слэша; измените регистр сегментов; добавьте или удалите строки запроса; сравните ответы для статических активов с динамическими маршрутами. Включите методы GET и HEAD, чтобы убедиться, что сервер возвращает ошибку 404 до каких-либо непреднамеренных перенаправлений или перезаписей.

Используйте трассировку неудачных запросов (FRT), когда она доступна, и перекрестно сверьтесь с accesslog для тех же временных меток. Эти трассировки показывают, какое правило или модуль заблокировали ресурс, или действительно ли ресурс отсутствует. Привяжите результаты к метрике панели управления: количество ошибок 404 по маршруту, по хосту и по учетной записи. Эта превосходная корреляция ускоряет расследование и выявляет текущие проблемные точки.

Для ресурсов, находящихся за уровнем перезаписи или маршрутизации, проверьте связанный web.config, правила перезаписи URL-адресов и любые конфигурации, подобные htaccess, которые IIS может учитывать через модули перезаписи. Если ошибка 404 указывает на проблему сопоставления, настройте правило или путь к файлу, затем повторно запустите тесты, чтобы подтвердить исправление, прежде чем переходить в рабочую среду. В случаях, когда ошибка 404 указывает на заблокированный ресурс, проверьте список блокировки или ограничения доступа и убедитесь, что они соответствуют предполагаемым шаблонам доступа.

Задокументируйте результаты на панели управления и поделитесь сводкой с владельцем сайта и руководством. При необходимости опубликуйте аналитические данные в LinkedIn для обеспечения видимости между командами. Процесс должен быть повторяемым: сохраните тестовые входные данные, запишите ответы и прикрепите связанные журналы из accesslog, чтобы они могли быть просмотрены владельцем учетной записи или командой безопасности.

Способы повышения устойчивости: создайте небольшую тестовую оболочку, которая перебирает список тестов, записывает коды состояния и помечает всплески. Используйте эти сигналы для принятия мер в отношении отсутствующих активов, обновления описей контента и блокировки шумных зондов по IP только в том случае, если это оправдано. Всегда поддерживайте текущий набор тестов в соответствии с инвентаризацией сайта и сопоставлением типов MIME, чтобы предотвратить регрессии.

Перед любыми изменениями убедитесь, что у вас есть одобрение владельца и план отката. Текущая панель мониторинга должна показывать, является ли уровень 404 стабильным, растущим или возвращается к базовому уровню. Хорошо управляемая система тестирования ускоряет реагирование на инциденты и помогает команде обеспечить более удобный пользовательский интерфейс.