Что такое ошибка доступа 403 и как ее исправить

Ошибка доступа 403 означает, что сервер понял запрос, но отказывает в доступе. Forbidden переводится как «запрещено».

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

Что такое ошибка доступа 403?

«403 forbidden что это значит»? Сервер понял запрос, но запрещает доступ к ресурсу: такой смысл несет код 403 Forbidden. Страница при этом может существовать, а сервер может работать исправно.

Код 401 сообщает, что запросу не хватает действительных данных авторизации. Код 404 означает, что сервер не нашел запрошенный ресурс; иногда сервер использует его, чтобы скрыть существование ресурса.

Вопрос «ошибка 403 что значит» возникает при разных сообщениях на экране. Их формулировку выбирает сервер, приложение или защитный сервис.

Forbidden: You don't have permission to access [directory] on this server
HTTP Error 403 – Forbidden
403 forbidden request forbidden by administrative rules
403 Forbidden
Access Denied You don't have permission to access
Удаленный сервер возвратил ошибку: (403) Запрещено
403. That’s an error
Access is denied

Надпись Access is denied сама по себе не доказывает наличие HTTP-кода 403.

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

Почему возникает ошибка доступа 403

Сервер возвращает 403 как при намеренной блокировке, так и при ошибке настройки. Причину ищут по журналу запросов, журналу ошибок и недавним изменениям сайта.

• Неверные права файлов и папок. Процесс веб-сервера не может прочитать файл или пройти через родительский каталог.
• Неверный владелец файлов. После переноса или распаковки архива файлы могут принадлежать другому пользователю. Одного изменения прав тогда недостаточно.
• Нет индексного файла. Посетитель открывает каталог, но сервер не находит разрешенный индексный файл, например index.php или index.html. Если просмотр содержимого каталога запрещен, сервер может вернуть 403.
• Правило запрещает доступ. Блокировка может находиться в .htaccess или конфигурации сервера. Примеры – правила deny/allow и Require, ограничивающие доступ по IP.
• Срабатывает защита. ModSecurity, другой WAF или защита CDN могут заблокировать запрос. Причиной бывает правило для IP, страны, адреса страницы или содержимого запроса.
• Приложение ограничивает пользователя. У аккаунта нет нужной роли либо плагин безопасности запрещает действие.

Сообщение request forbidden by administrative rules означает запрет по административным правилам.

Оно не указывает на конкретный файл или плагин. Точное правило ищите в журнале того компонента, который вернул отказ.

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

Если вы видите http error 403 на чужом сайте, серверные настройки вам недоступны. Однако неверный адрес и данные браузерного сеанса можно проверить самостоятельно.

1. Проверьте адрес в строке браузера. Если ссылка открывает каталог вроде /uploads/, перейдите на главную страницу домена и найдите материал через навигацию. Запрет просмотра каталога может быть намеренным.
2. Нажмите кнопку обновления рядом с адресной строкой. Если страница открылась, повторите исходное действие и убедитесь, что отказ не возвращается.
3. Выйдите из аккаунта через меню профиля сайта, если оно доступно. Войдите снова с нужной учетной записью и повторно откройте страницу.
4. Удалите cookies только проблемного сайта. Откройте настройки браузера и воспользуйтесь поиском по слову cookies. В разделе сохраненных данных сайтов найдите нужный домен и удалите его запись. После удаления потребуется повторный вход.
5. Очистите кэш, если браузер продолжает показывать прежний ответ. В настройках браузера найдите удаление данных просмотра. Отметьте кэшированные файлы, не выбирая пароли и историю без необходимости. Снова откройте исходный адрес.
6. Напишите владельцу через контакты на главной странице. Передайте адрес проблемной страницы, время ошибки с часовым поясом и снимок сообщения. Укажите, возник ли отказ до входа или после него.

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

Если 403 ошибка на сайте сохраняется, дальнейшие действия выполняет владелец. Повторный вход не отменит блокировку IP, страны или запрет для вашей роли.

Не отправляйте поддержке пароль и содержимое cookies.

Как владельцу найти причину 403 в логах

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

1. Откройте проблемную страницу и запишите время запроса с часовым поясом.
2. В панели хостинга откройте управление нужным сайтом. Найдите раздел журналов или логов, затем журнал ошибок веб-сервера. Если панель показывает файлы журналов, ищите error.log или error_log.
3. Найдите запись рядом с нужным временем. Сопоставьте адрес запроса и IP: соседняя строка может относиться к другому посетителю.
4. Если записи нет, посмотрите журнал доступа со статусом 403 и события защиты CDN/WAF. Отказ на внешнем защитном узле может не попасть в журнал сервера.

Формулировки зависят от сервера, поэтому читайте строку целиком.

Например, путь к файлу показывает, какой объект сервер не смог открыть. Идентификатор правила WAF помогает поддержке найти конкретную блокировку.

Если панель не показывает журналы, запросите у поддержки запись для конкретного URL и времени. Передайте также идентификатор запроса, если страница ошибки его содержит. Это полезнее просьбы «исправить 403» без подробностей.

Что делать, если возникла ошибка доступа 403 на вашем сайте

«ошибка 403 доступ запрещен как исправить»? Начните с журнала ошибок, чтобы выбрать подходящий способ для вашего WordPress-сайта.

Перед изменениями сохраните копию файлов и настроек. После каждого действия проверяйте тот же URL, на котором возникал отказ.

Шаг с .htaccess относится к Apache, когда сервер разрешает такие настройки. Nginx не читает .htaccess: проверьте его правила deny/allow, корневой каталог, индексный файл и права. Если nginx передает запросы Apache, запрет может возникнуть на любом из этих уровней.

Шаг 1 – Проверка файла .htaccess

Файл .htaccess хранит настройки Apache для каталога и вложенных папок. Он есть не на каждом WordPress-сайте. На других CMS не заменяйте его правила шаблоном WordPress.

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

Не оставляйте сайт без защитных настроек после диагностики.

1. Откройте файловый менеджер хостинга и каталог установки WordPress. Найдите папки wp-admin, wp-content и файл wp-config.php. Если скрытые файлы не видны, включите их отображение в настройках файлового менеджера.
2. Скачайте .htaccess на компьютер, чтобы создать резервную копию.
3. Для краткой проверки переименуйте файл в .htaccess.backup. Повторно откройте проблемную страницу. Если отказ сохранился, сразу верните исходное имя.
4. Если доступ восстановился, создайте новый .htaccess вручную по подходящим правилам WordPress. Сохраните резервную копию для возврата дополнительных настроек и отката.

Для одиночной установки WordPress в корне домена используйте базовые правила. Этот шаблон не подходит для Multisite и установки в подкаталоге. Варианты конфигурации описывает документация WordPress о .htaccess.

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

Создайте текстовый файл .htaccess рядом с index.php WordPress. Вставьте правила и сохраните файл без расширения .txt. Если файловый менеджер не умеет создавать скрытые файлы, загрузите подготовленный файл с компьютера.

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

Шаг 2 – Работа с правами доступа

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

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

Подключитесь к хостингу через FileZilla с параметрами из панели хостинга. При наличии SFTP используйте его для защищенной передачи.

1. Найдите каталог сайта, часто это public_html. Нажмите на папку правой кнопкой мыши и откройте диалог изменения прав. В нем ищите числовое поле и настройки обработки вложенных объектов.
2. Укажите 755 в числовом поле. Включите рекурсивную обработку вложенных каталогов и выберите применение только к папкам. Подтвердите изменение.
3. Снова откройте диалог прав для той же папки. Укажите 644, включите рекурсию и выберите применение только к файлам.
4. Дождитесь завершения обработки. Сразу восстановите записанные специальные права каждого исключения, прежде чем открывать сайт. Для отдельного файла или каталога задавайте исходное значение без рекурсии.
5. Проверьте права одной обычной вложенной папки и файла: соответственно 755 и 644. Убедитесь, что исключения сохранили исходные значения, затем откройте проблемную страницу.

Без рекурсии изменение не охватит вложенное дерево сайта.

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

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

Не ставьте 777: эти права разрешают запись всем пользователям системы. Если 755/644 не помогли, проверьте владельца файлов через поддержку хостинга. Для отката восстановите сохраненные значения.

Шаг 3 – Отключение плагинов WordPress

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

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

1. Откройте раздел «Плагины» в админке WordPress. Запишите названия активных расширений или сделайте снимок списка.
2. Отключите активные плагины через действия рядом с их названиями. После отключения всех записанных расширений повторите запрос к проблемной странице.
3. Если 403 исчез, включайте записанные плагины по одному. После каждого включения проверяйте тот же URL и исходное действие.
4. Если 403 вернулся, отключите последний включенный плагин и повторите запрос. Если админка заблокирована, временно переименуйте папку этого плагина через файловый менеджер, как описано далее.

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

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

1. Откройте wp-content/plugins в каталоге установки WordPress. Начните с недавно установленного или обновленного плагина, особенно плагина безопасности.
2. Запишите исходное имя его папки. Добавьте к имени суффикс -disabled, не меняя содержимое файлов.
3. Откройте проблемную страницу и попробуйте войти в админку. Если 403 сохранился, верните папке исходное имя и проверяйте следующий плагин.
4. Если доступ восстановился, оставьте папку переименованной на время исправления. Запишите название расширения и результат проверки для поддержки разработчика.

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

Этот прием не отключает обязательные плагины из mu-plugins и не удаляет уже записанные серверные правила.

Проблемный плагин оставьте выключенным до исправления его настроек или обновления.

Не включайте все расширения одновременно: вы потеряете результат диагностики.

Когда обращаться к хостинг-провайдеру

Обратитесь в поддержку хостинга, если лог указывает на владельца файлов, серверное правило или WAF. Приложите URL, время с часовым поясом, строку error.log и идентификатор запроса. Перечислите изменения, после которых ошибка появилась или исчезла.

Если сервер блокирует каталог без индексного файла, восстановите index.php из резервной копии либо исправьте корневой каталог сайта. Не включайте просмотр содержимого папок ради устранения 403: он может раскрыть служебные файлы.

Порядок диагностики владельца – лог, .htaccess, права, плагины, затем поддержка с собранными сведениями. Если журнал сразу показывает блокировку WAF, разбирайте конкретное правило без перебора файлов.

Не отключайте всю защиту сайта ради одного запроса.

Совет от нашей редакции: меняйте только один параметр за раз и записывайте результат. Так вы найдете причину запрета и сможете вернуть рабочие настройки.