Ошибка 403: почему сервер запрещает доступ и как это исправить

Ошибка 403 Forbidden значит, что сервер понял запрос и нашёл, что отдать, но сознательно отказал в доступе. Это не поломка, как 500, и не пустой адрес, как 404: где-то сработало правило запрета. Найти его можно в настройках сервера, .htaccess, правах на файлы или в защите хостинга.

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

Ошибка 403 Forbidden — ответ «доступ запрещён». Спецификация HTTP (RFC 9110) описывает его так: сервер понял запрос, но отказывается его выполнять. Сервер работает, адрес верный, но этому клиенту по этому адресу ходить нельзя.

Важная деталь из MDN: при ответе 403 повторный вход или новый пароль ничего не меняют. Запрет привязан не к тому, кто вы, а к правилу на сервере: закрытой папке, чёрному списку адресов, фильтру защиты. Если повторить тот же запрос без изменений, ответ будет тем же.

Чаще всего 403 видят в трёх ситуациях. Владелец открывает свой сайт после переноса или правки .htaccess. Посетитель заходит из страны или сети, которую режет защита хостинга. Поисковый робот упирается в антибот-фильтр, и страницы начинают пропадать из поиска.

Ошибка 403 — сервер жив и понял запрос, но правило запрета сработало. Искать нужно это правило, а не поломку.

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

Три кода из группы 4xx часто путают, хотя они сообщают разное. От того, какой код пришёл, зависит, что чинить.

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

С 401 тоже бывает путаница. По RFC 9110, если в запросе были данные для входа, а сервер ответил 403, он считает их недостаточными для доступа. Поэтому закрытый раздел после верного пароля может ответить 403, и это значит «права учётной записи не те», а не «пароль неверный».

Почему сервер закрывает доступ: частые причины

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

• Правила доступа по адресам — директивы deny в nginx или Require в Apache закрывают раздел для всех или для части IP-адресов. Часто остаются после техработ, когда сайт временно открывали только для своих.
• Нет индексного файла — запрос к папке без index.html или index.php, а вывод списка файлов выключен. Сервер не показывает содержимое каталога и отвечает отказом.
• Права на файлы и папки — веб-сервер не может прочитать файл после переноса, распаковки архива или смены владельца.
• Защита хостинга — файрвол, антибот-фильтр, блокировка по стране. Под раздачу попадают и люди, и поисковые роботы.
• Плагин безопасности CMS — блокирует адреса после неудачных входов, подозрительные запросы, целые подсети.
• Защита от хотлинка — запрет загружать картинки и файлы со сторонних сайтов, который по ошибке задевает и свой домен.

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

Кому именно закрыт доступ: вам, всем или роботам?

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

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

Как исправить 403 в nginx

В nginx доступ по адресам задают директивы allow и deny. Документация подчёркивает главное: правила проверяются в порядке записи до первого совпадения. Одна строка deny all; выше нужного allow закрывает раздел целиком.

Типичная конфигурация, в которой раздел открыт только офисной сети:

location /admin/ {
    allow 192.168.1.0/24;
    deny all;
}

Если такое правило попало в общий блок location / вместо раздела, сайт отдаёт 403 всем, кроме офиса. Проверьте, к какому location относится правило, и уберите лишнее.

Вторая частая причина — запрос к папке без индексного файла. Список файлов каталога nginx выводит модулем autoindex, который включается, когда модуль index не нашёл индексный файл. По умолчанию вывод списка выключен, и вместо него посетитель получает 403. Решение — положить индексный файл или поправить директиву index:

index index.php index.html;

Включать autoindex ради снятия 403 не стоит: так вы покажете всем содержимое папки, включая файлы, которые видеть никому не нужно.

Как исправить 403 в Apache и .htaccess

В Apache 2.4 доступ задаёт директива Require: ищите строки вроде Require all denied в конфигурации виртуального хоста и в файлах .htaccess по всей цепочке папок. Директивы из .htaccess действуют на каталог, где лежит файл, и на его дочерние каталоги, поэтому запрет из родительской папки закрывает и вложенные.

<Directory "/var/www/site/public">
    Require all granted
</Directory>

Со списком файлов в Apache то же, что в nginx. Если папку запросили без индексного файла, mod_autoindex выводит список файлов, только когда в Options разрешён Indexes. Когда листинг запрещён, сервер отвечает 403. Поправьте DirectoryIndex или положите индексный файл, а Options Indexes не включайте.

Отдельный случай — старые директивы Order, Allow, Deny из Apache 2.2 в .htaccess, перенесённом со старого сервера. Смешивать их с Require опасно: результат зависит от модулей совместимости. Перепишите правила на Require.

Мнение. Если 403 появилась после переноса сайта, сначала сравните .htaccess и права на файлы со старым сервером. Чаще всего виновато одно правило или один владелец файлов, а не сам сервер.

Как 403 влияет на поисковых роботов?

Для поисковика 403 — такой же отказ, как для человека. Google пишет, что не индексирует адреса, которые возвращают коды 4xx, а уже проиндексированные со временем удаляет. В справочнике кодов Яндекс Вебмастера про 403 сказано коротко: если хотите, чтобы страница индексировалась, разрешите к ней доступ.

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

Факт. Google просит не использовать коды 401 и 403, чтобы снизить частоту сканирования, а адреса, которые отдают коды 4xx, не индексирует.

Чтобы не перекрыть настоящих роботов, проверяйте их не по User-Agent, а по адресу. Яндекс советует определить доменное имя хоста обратным DNS-запросом по IP-адресу и сверить его прямым запросом. Нагрузку от роботов снижают другими способами — настройками скорости обхода в панелях вебмастера.

Что делать, если 403 появилась после переноса сайта?

Перенос на новый хостинг — самый частый повод для внезапной 403. Файлы скопированы, база на месте, а сайт отвечает «доступ запрещён». Причина почти всегда в том, что новый сервер устроен иначе, чем старый.

Пройдите по порядку. Сначала проверьте владельца файлов: если архив распаковали под учётной записью администратора, веб-сервер может не иметь права их читать. Затем права на папки: веб-серверу нужно право входа в каждую папку на пути к файлу. Потом сравните .htaccess со старым сервером: правила для Apache 2.2 на Apache 2.4 работают иначе, а на чистом nginx .htaccess не читается вовсе, и запреты из него нужно переносить в конфигурацию.

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

Когда 403 — правильный ответ

Ошибка 403 не всегда требует починки. Для служебных адресов это как раз нужный ответ:

• Панель администратора — вход только с офисных адресов или через VPN.
• Служебные папки и файлы — конфигурация, резервные копии, папка .git, журналы.
• Закрытые разделы — документы для партнёров, тестовая копия сайта.

Граница здесь такая: 403 на служебном адресе — норма, 403 на странице, которая должна приносить заявки или стоять в поиске, — ошибка. Если не уверены, какие адреса закрыты и почему, выгрузите все ответы 403 из журнала сервера и разберите их по разделам.

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

Источники

• RFC 9110: HTTP Semantics, 403 Forbidden — IETF
• 403 Forbidden — MDN
• Справочник по кодам статуса HTTP — Яндекс Вебмастер
• Ошибки на сайте — Яндекс Вебмастер
• Как проверить, что робот принадлежит Яндексу — Яндекс Вебмастер
• Как коды статуса HTTP влияют на сканирование — Google
• Модуль ngx_http_access_module — nginx
• Модуль ngx_http_autoindex_module — nginx
• .htaccess — Википедия