Сайт существует, домен работает, сервер отвечает, но вместо нужной страницы появляется 403 Forbidden. Иногда ошибка возникает сразу после переноса сайта, иногда после установки плагина или изменения настроек, а бывает, что владелец вообще ничего не менял.
У этой ошибки есть важная особенность. Сервер не потерял страницу и не обязательно сломался. Он получил запрос, понял, какой ресурс у него запрашивают, но по какой-то причине отказался предоставлять к нему доступ.
Именно поэтому бесконечное обновление страницы обычно ничего не меняет. Нужно выяснить, кто запретил доступ: файловая система, веб-сервер, .htaccess, система безопасности, CDN или само приложение.
Причин достаточно много, но искать их удобнее последовательно. Если сначала определить, где именно появляется запрет, исправление 403 часто занимает гораздо меньше времени, чем кажется.
Что означает ошибка 403 Forbidden
403 является HTTP-кодом ответа сервера. В упрощенном виде его смысл можно сформулировать так: запрос получен, но доступ к запрошенному ресурсу запрещен.
Этим 403 принципиально отличается от знакомой ошибки 404.
При 404 сервер сообщает, что не нашел запрошенный ресурс или не предоставляет его по этому адресу. При 403 ресурс может прекрасно существовать, но сервер не разрешает конкретный запрос.
Не следует путать 403 и с проблемами DNS. Если браузер уже получает от веб-сервера нормальный HTTP-ответ с кодом 403, значит запрос дошел достаточно далеко. Бездумная смена NS или A-записи в такой ситуации обычно не является правильным первым действием.
Запрет может относиться ко всему сайту, отдельному каталогу, конкретному файлу или только некоторым посетителям.
Это очень важная подсказка для диагностики.
Если 403 появляется на каждой странице, стоит искать общую настройку, затрагивающую весь сайт.
Если главная работает, но одна папка закрыта, причина, скорее всего, локальнее.
Если сайт прекрасно открывается с мобильного интернета, но показывает 403 через домашнего провайдера, нужно обратить внимание на ограничения по IP, защитные системы, CDN и другие механизмы фильтрации запросов.
Бывает и обратная ситуация: владелец сайта открывает административную страницу без проблем, а другой пользователь получает запрет. Тогда причиной может оказаться уже логика авторизации самого приложения.
Поэтому первая полезная проверка очень простая: определите масштаб ошибки.
- Не работает весь сайт или одна страница?
- Ошибка возникает у всех или только у вас?
- Открывается ли сайт через другую сеть?
- Работает ли административная панель?
- Что менялось непосредственно перед появлением ошибки?
Ответы на эти вопросы позволяют сразу отбросить часть возможных причин.
Почему сайт начинает выдавать 403
Одна из известных причин связана с правами доступа к файлам и каталогам.
На сервере недостаточно того, чтобы нужный файл физически существовал. Процесс веб-сервера должен иметь возможность получить к нему доступ. Если права или владельцы файлов настроены неправильно, сервер может отказать в выдаче ресурса.
Такая проблема особенно вероятна после переноса сайта, ручной распаковки архива или изменения разрешений.
Но устанавливать всему сайту права 777 в надежде убрать 403 нельзя.
Это плохой способ диагностики и потенциальная проблема безопасности. Более того, причина ошибки вообще может находиться не в файловых разрешениях.
На типичном хостинге для обычных файлов часто встречается значение 644, а для каталогов 755, но конкретная схема зависит от серверной конфигурации. Если права выглядят необычно, лучше сравнить их с рекомендациями своего провайдера.
Вторая большая группа причин связана с настройками веб-сервера.
На Apache правила для конкретного сайта могут находиться в файле .htaccess. С его помощью можно намеренно запрещать доступ к файлам, каталогам, определенным IP-адресам и запросам, соответствующим заданным условиям.
Поэтому 403 иногда появляется сразу после редактирования этого файла.
Особенно подозрительна ситуация, когда перед ошибкой владелец копировал готовый фрагмент конфигурации из инструкции в интернете.
Правило могло предназначаться для другой версии Apache, другого расположения сайта или вообще решать не ту задачу.
Если 403 возник непосредственно после изменения .htaccess, сохраните его копию и верните последнее рабочее состояние. Не удаляйте файл бездумно, если не знаете, какие функции сайта от него зависят.
У WordPress, например, через .htaccess на Apache могут работать правила постоянных ссылок и дополнительные настройки плагинов.
На сервере с Nginx ситуация устроена иначе. Nginx не использует .htaccess как Apache. Правила доступа находятся в его серверной конфигурации или задаются другими компонентами инфраструктуры.
Поэтому совет откройте .htaccess и исправьте 403 подходит далеко не каждому сайту.
Запрет также может быть настроен намеренно.
Администратор сервера способен разрешить доступ к определенной области только с заданных IP-адресов. Это нормальный способ защиты административных инструментов, тестовых площадок и внутренних разделов.
Проблема возникает, если IP пользователя изменился или правило было настроено неправильно.
В этом случае сайт делает именно то, что ему приказали: отклоняет запрос.
Отдельно стоит проверить наличие индексного файла.
Представим каталог, в котором нет index.php или index.html, а просмотр содержимого папки запрещен. При обращении непосредственно к каталогу сервер не может показать главную страницу и одновременно не имеет права вывести список файлов. В зависимости от конфигурации результатом может стать 403.
Поэтому после загрузки простого HTML-сайта полезно проверить, действительно ли главный файл находится в правильном каталоге и имеет ожидаемое имя.
Есть и более современная причина 403: системы защиты.
На хостинге может работать WAF, антивирусный модуль или другой фильтр запросов. Перед сайтом может находиться CDN или обратный прокси с собственными правилами безопасности.
Такая система анализирует запрос и при определенных условиях решает его заблокировать.
Иногда это именно то, чего мы хотим. Например, защитный фильтр останавливает очевидную попытку атаки.
Но возможны и ложные срабатывания.
Администратор WordPress сохраняет страницу с фрагментом программного кода, отправляет необычную форму или выполняет действие, которое защитный модуль считает подозрительным. Обычные страницы сайта при этом продолжают открываться, а конкретный запрос получает 403.
В таком случае изменение прав файлов ничего не исправит.
Как найти причину ошибки 403 на хостинге
Лучше всего начинать с последнего изменения.
Если пять минут назад сайт работал, затем вы отредактировали .htaccess и сразу получили 403, логичнее проверить этот файл, чем менять DNS или переустанавливать WordPress.
Если ошибка появилась после переноса, проверьте структуру каталогов, права и владельцев файлов.
Если проблема началась после включения защиты или CDN, временная проверка соответствующих правил даст больше информации.
Следующий шаг — посмотреть журналы сервера.
Логи особенно полезны тем, что позволяют заменить догадки конкретной причиной. В журнале может быть видно, что сервер отказал из-за настройки доступа, не смог пройти к файлу или запрос был заблокирован определенным модулем.
На виртуальном хостинге журналы обычно доступны через панель управления. Их расположение и набор зависят от провайдера.
Искать нужно запись, соответствующую времени возникновения ошибки и адресу проблемной страницы.
Если сайт находится на VPS, возможностей диагностики больше, но одновременно больше и ответственности. Нужно учитывать конфигурацию Apache или Nginx, владельцев файлов, правила доступа, системные журналы и промежуточные сервисы.
Для WordPress полезен еще один тест.
Если 403 появляется только при определенном действии в административной панели, например при сохранении записи, загрузке файла или изменении настройки, а остальные страницы работают, вероятность глобальной ошибки файловых прав становится ниже.
Здесь стоит проверить плагины безопасности, серверный WAF и журнал заблокированных запросов.
Если проблема возникла после установки конкретного плагина, его временное отключение может использоваться как диагностический тест. Но отключать все подряд без фиксации результатов не стоит.
После каждого действия проверяйте, изменилось ли поведение сайта.
Это позволяет установить причинно-следственную связь.
Полезно проверить сайт и из другой сети. Например, открыть его через мобильный интернет.
Если через одну сеть сайт доступен, а через другую постоянно возвращает 403, это сильная подсказка. Возможно, заблокирован конкретный IP или диапазон адресов.
Однако не спешите снимать всю защиту сайта только ради проверки.
Если используется CDN или WAF, сначала посмотрите журнал событий безопасности. Многие системы позволяют увидеть, какое правило сработало и почему запрос был отклонен.
На обычном виртуальном хостинге хороший момент для обращения в поддержку наступает тогда, когда вы уже можете описать проблему точно.
Вместо сообщения сайт не работает лучше написать: с 10:30 главная страница открывается, но раздел /catalog/ возвращает 403; .htaccess не менялся; проблема воспроизводится из разных сетей.
Поддержке будет значительно проще найти причину.
Что не стоит делать при появлении 403
Первая опасная идея — установить права 777 всему сайту.
Если причиной действительно являются разрешения, это может временно изменить поведение сервера, но одновременно открыть файлы значительно шире, чем требуется. Если же причина находится в WAF или правилах веб-сервера, действие вообще не поможет.
Не менее рискованно полностью очищать .htaccess, не сохранив копию.
В файле могут находиться правила CMS, редиректы со старых страниц, настройки HTTPS, ограничения доступа и другие важные директивы. После удаления 403 иногда исчезает, зато появляются совершенно новые проблемы.
Правильнее сначала сохранить исходный файл, а затем проверять изменения постепенно.
Не нужно сразу менять DNS.
Если запрос уже приходит на сервер и тот отвечает именно кодом 403, DNS свою основную задачу выполнил. Исключением может быть ситуация, когда домен направлен вообще не на тот сервер, но это сначала нужно подтвердить, а не предполагать.
Не стоит переустанавливать CMS только из-за одного HTTP-кода.
403 может формироваться еще до того, как запрос дойдет до WordPress или другого приложения. Переустановка в такой ситуации никак не повлияет на правило Apache, Nginx или внешнего защитного сервиса.
Еще одна плохая практика — отключить всю защиту сайта и оставить ее выключенной после того, как страница заработала.
Если виновником оказался WAF, это не обязательно означает, что он не нужен. Возможно, требуется скорректировать одно правило или добавить безопасное исключение для конкретного запроса.
То же относится к ограничениям по IP.
Сначала выясните, почему правило сработало, а затем меняйте только то, что действительно мешает нормальной работе.
После исправления полезно снова проверить не одну проблемную страницу, а несколько основных сценариев сайта.
Если менялся .htaccess, откройте внутренние страницы и убедитесь, что работают постоянные ссылки и редиректы. Если корректировались права, проверьте загрузку изображений и обновление CMS. Если создавалось исключение в защитном модуле, убедитесь, что оно не стало слишком широким.
Ошибка 403 сама по себе не говорит, какой файл нужно исправить или какую кнопку нажать в панели хостинга. Она сообщает более полезную вещь: запрос дошел до системы, которая решила отказать ему в доступе.
Поэтому оптимальная последовательность выглядит просто. Сначала определите, где именно появляется 403 и у кого она воспроизводится. Затем вспомните последние изменения, посмотрите логи, проверьте права и правила веб-сервера, после чего переходите к WAF, CDN и ограничениям по IP.
Так вместо случайного изменения десятка настроек можно найти конкретное правило, которое действительно запрещает доступ, и исправить именно его.
