BITSPARK / Статьи / Домен, хостинг и перенос

Ошибка 403 на сайте: что это значит и что делать владельцу

Коротко: ошибка 403 на сайте - ответ сервера о запрете доступа: сервер понял запрос, но отказывается его выполнить (RFC 9110). Причину код не называет, стандарт разрешает описать её в теле ответа. Причины со стороны владельца перечисляют справки хостингов Рег.ру и Timeweb, случаи с сервисом защиты - документация Cloudflare. Заказчику важно знать, кто держит доступ к хостингу и какие сведения передать исполнителю.

Ошибка 403 на сайте выглядит так: вместо страницы посетитель видит надпись «403 Forbidden», «Forbidden, доступ запрещен» или «Access denied». Причину конкретного сайта статья не определяет и исправление не обещает. Пример вымышленный: магазин настольных игр, сайт example.ru.

Источники открыты 10.10.2026. Русская MDN переведена сообществом, как сказано на самой странице. Английские цитаты приводятся с нашим переводом. Справки Рег.ру и Timeweb описывают хостинг своих компаний; условия других хостингов они не задают.

Что означает ошибка 403 Forbidden?

Коротко: код 403 Forbidden сообщает, что сервер понял запрос и отказывается его выполнить. Так определяют код RFC 9110 и английская MDN. Причину отказа код не называет: стандарт позволяет описать её в теле ответа, но не требует.

Сервер отвечает кодом статуса HTTP; код 403 определён в стандарте так:

«The 403 (Forbidden) status code indicates that the server understood the request but refuses to fulfill it. A server that wishes to make public why the request has been forbidden can describe that reason in the response content (if any).» Перевод наш: код 403 (Forbidden) показывает, что сервер понял запрос, но отказывается его выполнить. Сервер, который хочет обнародовать причину запрета, может описать её в содержимом ответа (если оно есть).

Английская MDN повторяет определение и дополняет его примером причины и ожиданием клиента:

«The HTTP 403 Forbidden client error response status code indicates that the server understood the request but refused to process it.» «The request failure is tied to application logic, such as insufficient permissions to a resource or action.» «Clients that receive a 403 response should expect that repeating the request without modification will fail with the same error.» Перевод наш: код ответа HTTP 403 Forbidden, ошибка клиента, показывает, что сервер понял запрос, но отказался его обрабатывать. Сбой запроса связан с логикой приложения, например с недостатком прав на ресурс или действие. Клиентам, получившим ответ 403, следует ожидать, что повтор запроса без изменений завершится той же ошибкой.

Русская MDN, изменённая 7 июля 2025, остаётся переводом сообщества:

«Код ответа на статус ошибки "HTTP 403 Forbidden" указывает, что сервер понял запрос, но отказывается его авторизовать.»

Три страницы формулируют по-разному: «refuses to fulfill it» в RFC 9110 (перевод наш: отказывается выполнить), «refused to process it» в английской MDN (перевод наш: отказался обрабатывать), «отказывается его авторизовать» в русском переводе. Определением в статье служат RFC 9110 и английская страница.

Что видно на экране и где искать причину?

Коротко: текст ошибки зависит от сайта; Рег.ру называет пять вариантов сообщения. Причину может содержать тело ответа: RFC 9110 это допускает, пример MDN показывает такой ответ. Если причины в ответе нет, её устанавливает исполнитель.

Рег.ру перечисляет сообщения: «В доступе на страницу отказано», «403 Forbidden», «Forbidden, доступ запрещен», «Forbidden You don't have permission to access» (перевод наш: запрещено, у вас нет разрешения на доступ), «Access denied». О смысле кода справка пишет так:

«Ошибка 403 говорит о том, что доступ к запрашиваемой странице запрещен или у пользователя нет прав на просмотр контента.»

Timeweb формулирует иначе: «Ошибка 403 (Forbidden) означает, что сервер получил запрос, но доступ к странице или файлу закрыт.» Обе справки описывают сам отказ; кто и почему закрыл доступ, код не сообщает.

Английская MDN показывает причину в теле ответа. Пример - запрос к API управления пользователями: клиент пробует удалить пользователя, передавая токен доступа. Ответ страница описывает так:

«The server has authenticated the request, but the action fails due to insufficient rights and the response body contains a reason for the failure» Перевод наш: сервер подтвердил подлинность запроса, но действие не выполнено из-за недостатка прав, и тело ответа содержит причину сбоя.

  • MDN, английская версия, раздел «Request failed due to insufficient permissions» (перевод наш: запрос не выполнен из-за недостатка прав)

В примере причина записана текстом: «Deleting users requires the 'admin' role.» (перевод наш: для удаления пользователей требуется роль администратора).

Чем 403 отличается от 401 и 404?

Коротко: 401 означает отсутствие действительных учётных данных у запроса. 403 - отказ сервера выполнить запрос, причём по RFC 9110 запрет возможен и по причинам, не связанным с учётными данными. 404, по тому же стандарту, - сервер не нашёл ресурс либо не желает раскрывать его существование.

Учётные данные - способ подтвердить, от чьего имени отправлен запрос, например логин с паролем (пояснение к термину). В таблице три кода по RFC 9110 и по справочнику Яндекса Вебмастера.

КодRFC 9110 (наш перевод)Справочник Яндекса Вебмастера, колонка «Как исправить»
401раздел 15.5.2: запрос не применён, потому что у него нет действительных учётных данных для целевого ресурса«Для доступа к документу необходимо вводить пароль или быть зарегистрированным пользователем.»
403раздел 15.5.4: сервер понял запрос, но отказывается его выполнить«Доступ к документу запрещен.»
404раздел 15.5.5: сервер не нашёл текущего представления целевого ресурса или не желает раскрывать, что оно существует«Документ не существует.»

Для 401 стандарт добавляет обязанность сервера прислать заголовок WWW-Authenticate. С 401 русская MDN сравнивает 403 так:

«Этот статус похож на 401, но в этом случае повторная аутентификация не будет иметь никакого значения.»

Ответ 404 вместо 403 стандарт допускает прямо:

«An origin server that wishes to "hide" the current existence of a forbidden target resource MAY instead respond with a status code of 404 (Not Found).» Перевод наш: сервер-источник, который хочет скрыть существование запрещённого целевого ресурса, может вместо этого ответить кодом 404 (Not Found).

Английская MDN уточняет:

«Server owners may decide to send a 404 response instead of a 403 if acknowledging the existence of a resource to clients with insufficient privileges is not desired.» Перевод наш: владельцы серверов могут решить отправить ответ 404 вместо 403, если нежелательно подтверждать существование ресурса клиентам с недостаточными привилегиями.

В русском переводе MDN этой фразы нет.

Определение 404 в разделе 15.5.5 RFC 9110 включает тот же случай: сервер не нашёл ресурс «or is not willing to disclose that one exists» (перевод наш: или не желает раскрывать его существование). Поэтому по определению стандарта ответ 404 у страницы, которая должна открываться, не исключает запрета доступа. Какой код вернёт сервер, решают его настройки; вопрос адресуйте исполнителю. Страницу 404 и проверку кода ответа разбирает статья Страница 404: что это, что на ней разместить и как проверить код.

Почему Search Console и RFC 9110 описывают 403 по-разному?

Коротко: Search Console пишет: при 403 «агент пользователя предоставил учетные данные, но не получил доступа». RFC 9110 допускает запрет и по причинам, с учётными данными не связанным. Формулировки расходятся; статья не выбирает между ними и относит каждую фразу к своей странице.

Справка Search Console, пункт «Страница заблокирована из-за ошибки 403 (доступ запрещен)»:

«Ответ HTTP 403 означает, что агент пользователя предоставил учетные данные, но не получил доступа.»

RFC 9110 в разделе 15.5.4 пишет шире:

«If authentication credentials were provided in the request, the server considers them insufficient to grant access. (...) However, a request might be forbidden for reasons unrelated to the credentials.» Перевод наш: если в запросе были учётные данные, сервер считает их недостаточными для доступа. Но запрос может быть запрещён по причинам, не связанным с учётными данными.

Формулировку, похожую на слова Search Console, содержит английская MDN о коде 401:

«A 401 Unauthorized is similar to the 403 Forbidden response, except that a 403 is returned when a request contains valid credentials, but the client does not have permissions to perform a certain action.» Перевод наш: 401 Unauthorized похож на ответ 403 Forbidden, но 403 возвращается, когда запрос содержит действительные учётные данные, а у клиента нет прав на выполнение определённого действия.

Справки хостингов Рег.ру и Timeweb перечисляют причины 403 без упоминания учётных данных: отсутствует файл главной страницы, файлы лежат в другой папке, действуют правила в файле настроек. Какая причина у вашего сайта, не определяет ни одна страница.

Что делать посетителю чужого сайта?

Коротко: Рег.ру советует посетителю проверить адрес, убедиться в наличии доступа, обновить страницу либо зайти позже, очистить кэш и cookies. Владельцу сайта нужны следующие разделы.

В разделе «Что может сделать пользователь со своей стороны» справка Рег.ру даёт шесть пунктов; первые четыре начинаются так:

  • «Проверьте правильность написания URL.»
  • «Убедитесь, что у вас действительно есть доступ к этому сайту.»
  • «Обновите страницу или зайдите позже.»
  • «Очистите кэш и cookies браузера.»

Кэш и cookies - сохранённые браузером данные посещённых сайтов (пояснение к термину). Пятый и шестой пункты раздела здесь не пересказываются.

Какие причины со стороны владельца называет Рег.ру?

Коротко: справка Рег.ру перечисляет семь случаев: блокировка услуги хостинга, главная страница, права, место файлов, файл .htaccess, версия ASP.NET, плагины WordPress. Условия принадлежат хостингу Рег.ру. Случай вашего сайта справка не определяет.

Раздел называется «Возможные причины и их решения, если проблема на стороне владельца сайта». Таблица пересказывает его по пунктам; в кавычках - слова справки.

Случай по Рег.руЧто предлагает справка
Заблокирована работа хостингаПроверить электронную почту: если приходило уведомление о блокировке, нужно следовать рекомендациям в письме
Некорректно задана главная страница сайтаВ корневой папке должен быть файл главной страницы (индексный файл), а в настройках - его название
Установлены некорректные права на файлы и каталогиКаталогам права «755», файлам «644»; справка просит проверить и изменить права
Файлы сайта находятся не в корневой директорииДомен обращается к корневой папке из настроек домена; если сайт загружен в другую папку или подпапку, возникает ошибка 403
Неправильно настроен файл .htaccess (только для хостинга Linux)Проверить правила в файле; справка называет условия «deny from all» и «RewriteRule»
Некорректная версия ASP.NET (только для хостинга для ASP.NET)Ошибка возможна, если сайт написан под ASP.NET 4.x, а на хостинге установлен ASP.NET 3.5
Некорректная работа плагинов в WordPressПроверить, не мешают ли плагины, обновить их и отключать по очереди

Блокировка услуги. Условия Рег.ру:

«Блокировка может произойти, если превышены технические ограничения тарифа или нарушены условия договора оферты. Перед блокировкой на контактный email владельца услуги придет предупреждение. У него будет 24 часа на устранение причины блокировки.»

Срок в 24 часа и письмо - условия Рег.ру; о других хостингах справка не говорит. Заказчику отсюда вопрос: чей email указан в услуге хостинга.

Главная страница и корневая папка. Индексным файлом справка называет файл главной страницы - той, что открывается при домене без адреса конкретной страницы. Условие справки: «Если в корневой папке сайта отсутствует файл с названием index.html или index.php, возникнет ошибка 403.» Оговорка:

«В качестве индексного файла может использоваться файл, отличный от index.html или index.php. Но название данного файла должно быть указано в настройках.»

Корневая папка - та, которую указали в настройках домена. Если сайт загружен в подпапку, по справке «возникнет ошибка 403».

Права. Права на файлы и каталоги - настройка, какие действия с файлом или папкой разрешены (пояснение к термину). Числа справки: «755» для каталогов и «644» для файлов, с вводными словами «В большинстве случаев». На странице Timeweb этих чисел нет.

Файл .htaccess - файл веб-сервера Apache; Cloudflare называет его местом правил доступа («Apache .htaccess file», пояснение к термину). Рег.ру относит этот случай к хостингу Linux и советует: «Чтобы поправить, обратитесь к разработчикам сайта.» Что такие правила способны вернуть 403, подтверждает документация Apache:

«The [F] RewriteRule flag causes a 403 Forbidden response to be sent. Using this, you can deny access to a resource based on arbitrary criteria.» Перевод наш: флаг [F] правила RewriteRule вызывает отправку ответа 403 Forbidden. С его помощью можно закрыть доступ к ресурсу по произвольным критериям.

С ASP.NET Рег.ру предлагает другой путь: «Чтобы изменить версию ASP.NET для услуги хостинга, оставьте заявку в службу поддержки.»

О плагинах справка пишет: «Если ваш сайт сделан на WordPress, нужно проверить, не мешают ли работе сайта плагины.» Плагины - дополнения, расширяющие возможности сайта (пояснение к термину).

Проверки файлов и настроек справка сопровождает инструкциями по панелям ispmanager, cPanel и Plesk.

Что добавляет справка Timeweb?

Коротко: Timeweb тоже связывает 403 с файлом главной страницы, правами и местом файлов, но условия иные: другие имена индексных файлов, другое описание прав. Появляются блокировка IP-адреса и блокировка PHP-файлов через .htaccess. Условия двух провайдеров различаются.

Страница Ошибка 403: причины и способы исправления | Справочный центр Timeweb написана о виртуальном хостинге Timeweb. В таблице - пункты, которые есть в обеих справках.

ПунктРег.руTimeweb
Имена индексных файловindex.html или index.php; другое имя допустимо, если оно указано в настройкахindex.html, index.htm или index.php; имя файла целиком в нижнем регистре
Правакаталоги «755», файлы «644»«Все директории должны предоставлять права на выполнение для владельца.»
Место файловкорневая папка из настроек доменадиректория /site/public_html, где site - название сайта; основной сайт - public_html в домашней директории аккаунта
Файл .htaccessправила с условиями deny from all и RewriteRuleблокировка IP-адреса и блокировка PHP-файлов

Индексный файл Timeweb описывает так: «Индексного файла нет в директории public_html или его имя написано некорректно.» И дальше: «Сервер открывает сайт с индексного файла с именем index.html, index.htm или index.php.»

О месте файлов страница пишет: «Файлы сайта загружены в неправильную директорию.» О файле настроек: «Ваш IP-адрес заблокирован через файл .htaccess.»

Отдельный случай Timeweb описывает так: «Файлы с расширением .php блокируются через .htaccess». Страница связывает его с заражением сайта и пишет: «Просто удалить строки недостаточно - нужно устранить причину заражения, иначе они появятся снова.» Как устраняют заражение, в этом пункте страницы не сказано.

Отсутствие индексного файла как причину 403 называют справки Рег.ру и Timeweb. В прочитанных разделах RFC 9110 и на страницах MDN и Cloudflare этой причины нет.

Когда 403 отдаёт сервис защиты перед сайтом?

Коротко: документация Cloudflare различает 403 от сервера сайта и 403 от самого сервиса: сработали правила WAF, уровень безопасности, защита от DDoS. Страница относится к одному сервису; о других она не говорит. Что подключено к вашему сайту, спросите исполнителя.

Cloudflare работает между посетителем и сервером сайта. Источник ответа его страница об ошибке 403 определяет так:

«If you encounter a 403 error without the Cloudflare branding, this means that the error is being returned directly by the origin web server, not Cloudflare.» Перевод наш: если вы столкнулись с ошибкой 403 без оформления Cloudflare, это значит, что ошибку возвращает непосредственно исходный веб-сервер; Cloudflare её не возвращает.

Причин на исходном сервере страница называет три: правила доступа веб-сервера (например, в файле Apache .htaccess), правила Mod_security, запреты по IP-адресам и диапазонам.

Собственные ответы 403 сервис, по странице, отдаёт при условиях:

«Cloudflare may serve 403 responses in the following scenarios:» Перевод наш: Cloudflare может отдавать ответы 403 в следующих случаях.

Среди условий страница называет: нарушение запросом правила WAF, правила с действием challenge или block, настройки Security Level, DDoS Protection, Browser Integrity Check и Validation Checks. Это названия функций сервиса так, как они написаны в документации. Там же сказано, что Cloudflare «may also serve an unstyled 403 error page in specific cases» (перевод наш: может также отдавать страницу ошибки 403 без оформления в особых случаях). Ответ без оформления Cloudflare сам по себе не доказывает, что его вернул исходный сервер.

Заказчику это даёт один вопрос исполнителю: подключён ли перед сайтом сервис защиты. И один признак для обращения: есть ли в окне ошибки оформление такого сервиса.

Кто устраняет причины 403?

Коротко: Рег.ру адресует проверки владельцу услуги хостинга, разработчикам сайта и службе поддержки: блокировку услуги - владельцу и поддержке, файл .htaccess - разработчикам, версию ASP.NET - поддержке хостинга. Документация Cloudflare говорит о правилах и настройках самого сервиса. Кто из них отвечает за ваш сайт, выясните до запуска.

Рег.ру начинает с общей оценки:

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

Дальше справка называет разных исполнителей:

СлучайКого называет источник
Блокировка услугипрочитать письмо владельцу услуги и следовать ему либо обратиться в техническую поддержку (Рег.ру)
Файл .htaccessразработчики сайта (Рег.ру); файловый менеджер панели управления (Timeweb)
Версия ASP.NETслужба поддержки хостинга (Рег.ру)
Главная страница и корневая папкапанель управления хостингом (Рег.ру)
Правила и настройки сервиса защитысам сервис (документация Cloudflare)

Набор действий, доступных владельцу, зависит от вида хостинга: об этом пишет статья Виртуальный хостинг, VPS или выделенный сервер: что выбрать, раздел об администрировании сервера. Таблицу Рег.ру о том, кто устраняет причины ошибки 502, приводит статья Ошибка 500 на сайте: что это значит и что делать владельцу.

Что говорят справки поисковиков о странице с кодом 403?

Коротко: Google пишет: URL с кодом 4xx не индексируются, проиндексированные удаляются из индекса, а 401 и 403 не следует использовать для ограничения частоты сканирования. Яндекс: чтобы страница индексировалась, нужно разрешить доступ к ней. Срока, за который страница с кодом 403 выпадает из индекса или возвращается в него, эти справки не называют; позиций и трафика статья не обещает.

Индекс - список страниц, которые знает поиск (пояснение к термину). Справка Google о кодах статуса пишет о классе 4xx, куда входит 403:

«В Google Поиске не индексируются URL, которые возвращают код статуса 4xx, а URL, которые уже проиндексированы и возвращают код статуса 4xx, удаляются из индекса.»

«Роботы Google игнорируют любой контент, получаемый с URL, которые возвращают код статуса 4xx.»

«Все ошибки 4xx, за исключением 429, обрабатываются одинаково: поисковые роботы Google сообщают следующей системе обработки, что контент отсутствует.»

«Не используйте коды статуса 401 и 403 для ограничения частоты сканирования.»

Справка Search Console об индексировании страниц дописывает про 403:

«Учтите, что робот Googlebot никогда не предоставляет учетные данные, поэтому сведения об ошибке, которые возвращает сервер, некорректны. Страница не будет проиндексирована.»

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

Справочник Яндекса Вебмастера называет код 403 так: «Доступ к ресурсу запрещен/Forbidden». В колонке «Как исправить» для него стоят две строки: первая приведена в таблице выше, вторая:

«Если вы хотите, чтобы страница индексировалась, необходимо разрешить доступ к ней.»

Страница инструмента проверки ответа сервера добавляет общее правило любому ответу, отличному от 200 OK:

«Когда ответ сервера отличается от HTTP-статуса с кодом 200 OK или отображается сообщение из списка ниже, страница не может участвовать в результатах поиска.»

Шаги инструмента изложены в статье об ошибке 500, раздел «Как проверить код ответа сервера самому?»: Ошибка 500 на сайте: что это значит и что делать владельцу.

Что сообщить при обращении об ошибке 403?

Коротко: готового списка для обращения справки об ошибке 403 не содержат. Шесть сведений собраны из причин, которые справки называют: адрес и сообщение, место появления ошибки, письма хостинга, оформление страницы ошибки, изменения перед сбоем, текст самой страницы. Сведения об ошибках 5xx собраны в статье об ошибке 500.

Таблица связывает каждое сведение с источником.

СведениеОснование
Адрес страницы и сообщение в окнеРег.ру перечисляет варианты сообщения
Где появляется ошибка: главная, раздел или все адресаУсловие Рег.ру про индексный файл относится к домену без конкретной страницы; Рег.ру и Timeweb называют причиной место файлов
Приходили ли письма хостинга о блокировке услугиРег.ру пишет о предупреждении на контактный email
Есть ли в окне ошибки оформление сервиса защитыCloudflare различает ответ исходного сервера и ответ сервиса
Что менялось перед ошибкой: загрузка файлов, правила доступа, плагиныРег.ру называет место файлов, .htaccess и плагины WordPress, Timeweb - место файлов и .htaccess
Текст в окне ошибкиRFC 9110 допускает описание причины в содержимом ответа, пример MDN показывает причину в теле ответа

Пример обращения для вымышленного сайта example.ru:

Сайт example.ru (интернет-магазин настольных игр) показывает «403 Forbidden» на главной странице и в каталоге.
Сегодня в 11:40 по московскому времени мы загрузили новый раздел каталога через панель хостинга.
Страница ошибки без фирменного оформления сервиса защиты, скриншот во вложении.
Письма от хостинга о блокировке услуги на контактный email не приходили.

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

Какие доступы выяснить у подрядчика до запуска?

Коротко: до запуска можно выяснить, кто владелец аккаунта хостинга, чей email указан в услуге, кто правит файлы и правила доступа и подключён ли сервис защиты. Вопросы построены по справкам Рег.ру, Timeweb и документации Cloudflare.

Из процесса, описанного на главной странице BITSPARK, к теме статьи относятся два шага. Разработка: «Верстаем, программируем и подключаем сервисы. Технологии выбираем под задачу.» Запуск: «Проверяем desktop и mobile, скорость, формы и ключевые сценарии - затем запускаем.»

Вопросы о доступах:

  • На кого оформлен аккаунт хостинга и у кого есть доступ к панели управления? Справки Рег.ру и Timeweb отправляют в панель управления, когда проверяют файлы и настройки. Оформление аккаунта разбирает раздел «На кого оформлять аккаунт хостинга?» статьи Виртуальный хостинг, VPS или выделенный сервер: что выбрать.
  • Чей контактный email указан в услуге хостинга и кто читает письма провайдера? Рег.ру пишет о предупреждении на контактный email владельца услуги.
  • Кто после сдачи сайта правит файлы, права и правила доступа, в том числе файл .htaccess? Рег.ру отсылает по поводу файла .htaccess к разработчикам сайта.
  • Подключён ли перед сайтом сервис защиты и кто управляет его правилами? Документация Cloudflare называет правила и настройки сервиса среди источников ответа 403.
  • Какие страницы или разделы закрыты намеренно и кто может их открыть? Timeweb пишет, что при 403 «доступ закрыт намеренно или из-за неверных настроек».

Источники

Страницы открыты 10.10.2026.

Обсудить проект в Telegram: t.me/billioniks

Читайте по теме

Все статьи раздела «Домен, хостинг и перенос» →