Как убрать 404 заменив файл web config

Обновлено: 06.07.2024

Рассмотрим два подхода, как настроить страницы ошибок. Они в целом похожи, какой выбрать – решать вам.

Для начала вспомним, что означают наиболее популярные коды ошибок, которые отдает сервер.

Код ответа 200. Это значит что все ОК. Запрос клиента обработан успешно, и сервер отдал затребованные клиентом данные в полном объеме. Например, пользователь кликнул по гиперссылке, и в ответ на это в браузере отобразилась нужная ему информация. Код ответа 404. Это означает, что запрошенный клиентом ресурс не найден на сервере. Например, указанная в адресе гиперссылки статья не найдена, или *.pdf файл был удален и теперь недоступен для скачивания. Код ответа 500. Внутренняя ошибка на сайте. Что-то сломалось. Это может быть все что угодно, от неправильно написанного кода программистом, до отказа оборудования на сервере.

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

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

Вариант 1. Ссылка на статичные заранее подготовленные html-страницы.

Первым делом в файле web.config в разделе system.web добавляем новую секцию customErrors со следующими настройками:

Атрибут mode="On" определяет, что пользовательские страницы ошибок включены. Также допустимы значения Off / RemoteOnly .

Атрибут redirectMode="ResponseRewrite" определяет, следует ли изменять URL-адрес запроса при перенаправлении на пользовательскую страницу ошибки. Естественно, нам этого не нужно.

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

И уже внутри этой секции мы определяем два кода, для которых у нас будут кастомные страницы ошибок.

Далее, как видно из настроек выше, нам понадобятся *.aspx файлы, на которые будет делаться редирект. Обратите внимание, что мы ссылаемся именно на *.aspx файлы, а не на *.html. Эти файлы являются проходными, служебными, в них содержатся настройки для ответа сервера. Содержимое файла 404.aspx:

В коде выше мы указываем путь непосредственно до конечного *.html файла, а также дополняем настройки ответа сервера. Указываем код ответа, тип отдаваемого контента и кодировку. Если не указать кодировку, то браузер пользователя может интерпретировать ответ от сервера как не отформатированную строку, и, соответственно, не преобразует ее в html-разметку. А если не указать StatusCode = 404 , то получится следующая интересная ситуация:

Попробуйте собственноручно намеренно убрать какую-нибудь из объявленных на данный момент настроек из секции customErrors и понаблюдайте за результатом.

Также по аналогии создаем подобный *.aspx файл для ошибки 500.

И уже после этого нам нужно создать статичные html-файлы, соответственно для ошибок 404 и 500. Пусть они лежат в корне нашего проекта.

Или же когда система маршрутизации в MVC-приложении не может определить, к какому маршруту отнести запрошенный пользователем URL-адрес:

Также проверьте папку App_Start . Если вы создали не пустое приложение, а работаете над реальным проектом, там может находиться класс FilterConfig , в котором регистрируются все глобальные фильтры в приложении. В методе регистрации удалите строчку кода, где регистрируется HandleErrorAttribute , в нашем случае он не понадобится.

Вот такой комплекс мер нужно предпринять, чтобы настроить обработку ошибок 404, 500, и любых других. Это настройки в файле web.config, и добавление в наш проект статичных файлов.

Вариант 2. Обработка ошибок с использованием специального контроллера.

Второй подход немного отличается от первого. Здесь нам не понадобится секция customErrors , так как обработку всех ошибок мы будем передавать сразу из приложения на уровень сервера, и он уже будет решать что делать. Можно удалить или закомментировать эту секцию в файле web.config.

Далее создадим специальный контроллер, который будет принимать все ошибки, которые мы хотим обрабатывать:

Также создадим соответствующие представления с нужной нам красивой разметкой.

Вариант 3. Фильтр HandleErrorAttribute

Замечу, что есть еще один способ взять под свой контроль обработку ошибок в приложении – это наследоваться от стандартного класса HandleErrorAttribute и написать свой фильтр. Но это уже более частный случай, когда нужно реализовать какую-то особенную логику при возникновении той или иной ошибки. В большинстве же более менее стандартных приложений наша проблема решается двумя выше описанными способами и в этом фильтре нет необходимости. Более подробную информацию, как работать с классом HandleErrorAttribute можно найти в официальной документации в интернете по этой ссылке.

В статье рассмотрим, что означает ошибка 404 на сайте. Ошибка 404 page not found — это код ответа сервера, который сообщает пользователю, что сервер не может найти запрашиваемые данные. Почему такое может произойти? Есть несколько возможных причин:

Как убрать ошибку 404 на сайте, созданном на CMS (WordPress, Joomla, 1С-Битрикс и т.д.)

В большинстве случаев проблема связана с отсутствием конфигурационного файла .htaccess. Как избавиться от ошибки 404? Создайте в корневой папке сайта пустой текстовый файл с расширением .htaccess и добавьте в него стандартные директивы для используемой CMS. Стандартные директивы приведены в статье: Файлы .htaccess для популярных CMS.

Важно: в панели управления cPanel файл .htaccess по умолчанию скрыт (т.е. он существует, но не виден). Следуйте инструкции, чтобы включить отображение файла. Затем сверьте его содержимое со стандартным.

Если файл .htaccess существует и его содержимое корректно, а ошибка 404 not found сохраняется, обратитесь в техническую поддержку.

Если вы видите иную страницу ошибки, которую отдает CMS сайта. Например:

Ошибка на WordPress

Пользовательская ошибка 404 not found

Как быстро устранить ошибку 404 на сайте, созданном без использования CMS

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

Что делать? Откройте корневую папку сайта в панели управления хостингом и проверьте, находятся ли в ней файлы вашего сайта.

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

Если файлы существуют и находятся в корневой папке, обратитесь в техническую поддержку.

Открывается только главная страница сайта, на внутренних страницах ошибка 404 или 500

На хостинге Linux

Если у вас ISPmanager, проверьте, не включены ли Автоподдомены. Если они включены, отключите их, проверьте актуальность проблемы.

В остальных случаях для устранения внутренней ошибки 404 или 500, перейдите в корневую папку сайта: Как узнать корневую папку сайта
Создайте файл .htaccess (или замените его) со следующим содержимым:

Если у вас хостинг Windows

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

Что будет, если не исправлять ошибку 404

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

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

Сделайте страницу 404 полезной

Вот несколько советов по созданию страницы:

дизайн этой страницы должен соответствовать всему ресурсу (цвет, шрифт, иллюстрации),
поместите ссылку на главную страницу,
добавьте дайджесты последних публикаций на сайте,
поместите контакты организации (номер телефона, адрес) и службы поддержки,
можно предложить действия для решения проблемы доступа к странице.

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

Автор: Soroush Dalili

На серверах с IIS7 (и выше) также возможно осуществление подобных трюков путем загрузки или создания файла web.config. С небольшими изменениями некоторые из этих техник могут быть применимы и к IIS6. Далее будет продемонстрировано несколько версий web.config для обхода ограничений в файловых загрузчиках.

Запуск web.config как ASP-файла

Некоторые IIS-сервера поддерживают ASP-файлы, однако загрузить сам файл с расширением .ASP не представляется возможным. В этом случае можно использовать web.config для запуска ASP-кода:

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<system.webServer>
<handlers accessPolicy="Read, Script, Write">
<add name="web_config" path="*.config" verb="
*" modules="IsapiModule" scriptProcessor="%windir%\system32\inetsrv\asp.dll"
resourceType="Unspecified" requireAccess="Write" preCondition="bitness64" />
</handlers>
<security>
<requestFiltering>
<fileExtensions>
<remove fileExtension=".config" />
</fileExtensions>
<hiddenSegments>
<remove segment="web.config" />
</hiddenSegments>
</requestFiltering>
</security>
</system.webServer>
</configuration>

Удаление скрытых сегментов

Иногда загрузчики фалов используют скрытые сегменты (Hidden Segments) из IIS Request Filtering, например, директории APP_Data и App_GlobalResources, закрывая к загруженным файлам прямой доступ.

Однако этот метод легко обходится путем удаления скрытых сегментов при помощи следующей версии web.config:

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<system.webServer>
<security>
<requestFiltering>
<hiddenSegments>
<remove segment="bin" />
<remove segment="App_code" />
<remove segment="App_GlobalResources" />
<remove segment="App_LocalResources" />
<remove segment="App_Browsers" />
<remove segment="App_WebReferences" />
<remove segment="App_Data" />

</hiddenSegments>
</requestFiltering>
</security>
</system.webServer>
</configuration>

Теперь загруженные файлы доступны напрямую.

Создание XSS уязвимости на стандартной странице об ошибках

Часто злоумышленники внедряют в сайт XSS-уязвимость, используя функцию загрузки файлов.

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

Другие техники

Изменение или создание web.config может привести к серьезным проблемам с безопасностью. В дополнении к вышеуказанным техникам, использование других версий файла web.config может привести к другим нежелательным последствиям. Некоторые примеры я привел ниже (соответствующая версия web.config легко находится через поисковую систему):

Использование разрешенных расширений для запуска файлов с другим расширением: когда использование расширений ASP и PHP в целом разрешено на сервере, но запрещено в папке, в которую загружаются файлы.

Злоупотребление страницами об ошибках или правилами перезаписи URL’ов для перенаправления пользователей или взлома сайта: когда загруженные файлы (например, PDF или JavaScript) доступны пользователям напрямую.

Манипуляция MIME-типами загружаемых файлов: когда загрузка HTML (или любых других) файлов запрещена или когда таблица MIME-типов содержит лишь определенные расширения.

Я недавно переехал на хост, и мне пришлось снова настраивать ошибки клиентов в IIS.

Я могу перейти на страницы администратора и ошибок IIS следующим образом:

Затем я могу перейти к настраиваемым ошибкам и настроить следующие параметры:

Это создает мой файл web.config следующим образом:

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

Я не понимаю, что мне еще нужно делать.

2 ответа

У меня была аналогичная проблема, когда у меня была пользовательская страница 404 в / Error / Missing, но она не отображалась для статических файлов, которых не было, или для папок / каталогов, которые существуют (но не должны обслуживаться MVC ). Контроллер для отсутствующей страницы имеет следующее:

Также я не получал свою страницу с пользовательской ошибкой, если возвращал в контроллер следующее:

Я мог бы изменить ошибки IIS по умолчанию на пустую страницу, если бы установил PassThrough:

При изменении его на «Заменить» снова отображаются ошибки IIS по умолчанию.

У меня также был раздел в моем web.config, но я удалил его, так как я использую IIS 8.5, похоже, он больше не нужен.

Наконец, я натолкнулся на этот вопрос, посмотрел на другой ответ на этот вопрос и понял, что могу попробовать ResponseMode в каждой строке ошибки. Я думал, что в этом нет необходимости, поскольку у меня был установлен defaultResponseMode, но это имеет значение !!

Я поместил все эти подробности здесь, так что, надеюсь, это покажется кому-то еще, ищущим то же самое, что и я - надеюсь, это поможет!

Читайте также: