Ошибка 403 Forbidden: что означает и как исправить на сайте

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

В типичной схеме ответ может сформировать CDN, Nginx, приложение или модуль защиты. У каждого источника свои журналы и настройки. Исправление наугад способно открыть закрытый раздел или, наоборот, сломать доступ ко всему сайту.

Что сервер сообщает кодом 403

HTTP — протокол, по которому браузер запрашивает страницу. Числовой статус описывает результат запроса. Стандарт определяет 403 как отказ сервера выполнить уже понятый запрос.

Это отличается от соседних кодов:

• 401 Unauthorized требует действительные данные аутентификации и сопровождается указанием способа входа;
• 403 Forbidden сообщает, что доступ не предоставлен — даже введённые данные могли оказаться недостаточными;
• 404 Not Found означает, что ресурс не найден. Сервер вправе вернуть 404 вместо 403, если не хочет подтверждать существование закрытого ресурса.

Сам код не называет причину. Запрет по IP, неправильные права файла и отказ приложения выглядят в браузере одинаково.

Зафиксируйте адрес и источник ответа

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

curl -sS -D - -o /dev/null https://example.com/problem-page

В первой строке должен быть виден статус, например HTTP/2 403. Заголовки server, via и служебные поля CDN иногда подсказывают, какой узел ответил, но не являются доказательством: их можно изменить или скрыть.

Сравните ещё три запроса:

1. Главную страницу и заведомо существующий открытый файл.
2. Тот же URL после входа и в приватном окне без cookies.
3. Проблемный URL непосредственно на origin-сервере, если перед ним стоит CDN и у вас есть административный способ такого доступа.

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

Найдите запись запроса в Nginx

На VPS посмотрите активные пути журналов и сообщения вокруг записанного времени:

sudo nginx -T 2>/dev/null | grep -E 'access_log|error_log'
sudo tail -n 100 /var/log/nginx/access.log
sudo tail -n 100 /var/log/nginx/error.log

nginx -T печатает собранную конфигурацию, включая подключённые файлы. Не публикуйте её целиком: внутри могут быть адреса внутренних служб. Пути /var/log/nginx/... приведены для распространённой пакетной установки; используйте значения из собственной конфигурации.

В access log найдите нужные время, путь и статус 403. В error log важна строка с тем же запросом. Сообщение permission denied указывает на права файловой системы. Фраза directory index ... is forbidden означает, что запрос пришёл в каталог, а подходящего индексного файла или разрешённого списка файлов нет. Если error log молчит, запрет могло сформировать приложение или явное правило доступа.

Подробнее о чтении полей рассказано в материале про диагностику по логам Nginx.

Проверьте, какой файл должен открыть Nginx

Для статической страницы Nginx сначала выбирает блок server по адресу сайта, затем location по пути запроса и только после этого строит путь к файлу через root, alias или try_files. Посмотрите активную конфигурацию нужного сайта:

sudo nginx -T

Найдите server_name example.com, затем проверьте root, index и подходящий location. Например, при root /srv/www/example.com/public; запрос /docs/ обычно ведёт к каталогу /srv/www/example.com/public/docs/, а директива index index.html; заставляет Nginx искать в нём index.html.

Подтвердите существование итогового пути:

ls -ld /srv/www/example.com/public/docs
ls -l /srv/www/example.com/public/docs/index.html

Если файла нет, права менять бессмысленно: нужно исправить публикацию, root или имя индексного файла. Особенности построения пути подробно разобраны в статье про location, root, alias и try_files.

Проверьте права каждого каталога в пути

Рабочий процесс Nginx обычно читает файлы не от имени владельца проекта, а от отдельного пользователя, например www-data. Команда namei раскладывает полный путь на части и показывает владельца и режим каждой из них:

namei -l /srv/www/example.com/public/docs/index.html
sudo -u www-data test -r /srv/www/example.com/public/docs/index.html
echo $?

Код 0 после test означает, что пользователь может прочитать файл. Но для доступа к нему также требуется право x — проход — на каждом родительском каталоге. Поэтому закрытый /srv/www/example.com способен вызвать 403, даже если у index.html есть право чтения.

Перед изменением сохраните текущие значения:

stat -c '%A %a %U:%G %n' \
  /srv/www/example.com \
  /srv/www/example.com/public \
  /srv/www/example.com/public/docs \
  /srv/www/example.com/public/docs/index.html

Исправляйте только подтверждённый участок. Одна из понятных моделей — владелец deploy, группа www-data, каталоги 750, файлы 640. Она подходит лишь тогда, когда процесс Nginx действительно входит в эту группу, а другим локальным пользователям доступ не нужен:

sudo chown deploy:www-data /srv/www/example.com/public/docs
sudo chown deploy:www-data /srv/www/example.com/public/docs/index.html
sudo chmod 750 /srv/www/example.com/public/docs
sudo chmod 640 /srv/www/example.com/public/docs/index.html

Эти команды меняют только указанный каталог и файл. Не применяйте рекурсивный chmod ко всему серверу и не выдавайте 777: запись постороннему процессу не нужна для раздачи страницы. После изменения повторите namei, test и HTTP-запрос. Если 403 сохранился, верните режимы и владельцев из сохранённого вывода, а затем продолжите диагностику.

Найдите явное правило запрета

Nginx может запрещать адрес, метод запроса, IP или весь каталог. В собранной конфигурации ищите директивы доступа рядом с выбранным server и location:

sudo nginx -T 2>/dev/null | grep -nE 'deny|allow|auth_basic|limit_except|return 403'

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

Если правило ошибочно, сохраните копию изменяемого файла, внесите минимальную правку и проверьте синтаксис:

sudo nginx -t
sudo systemctl reload nginx

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

Когда запрет возвращает приложение

Если Nginx передаёт запрос приложению, в access log приложения или в полях upstream может быть собственный статус 403. Частые причины — роль пользователя, защита формы от поддельного запроса, недействительный токен, запрет метода, закрытый API или правило безопасности.

Проверьте журнал приложения за то же время и сопоставьте запрос по идентификатору, если он передаётся между Nginx и backend. Не записывайте в журнал cookies, пароли и заголовок Authorization. Для одного воспроизводимого запроса достаточно пути, метода, времени, безопасного request ID и причины отказа, которую приложение уже знает.

Если 403 возникает после отправки формы, сравните GET и POST: открытая страница не гарантирует разрешение на изменение данных. Если ошибка зависит от учётной записи, проверяйте назначенную ей роль, а не отключайте проверку для всех пользователей.

Контрольная проверка после исправления

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

curl -sS -D - -o /dev/null https://example.com/problem-page

Затем убедитесь, что закрытые адреса остались закрытыми. Полезный набор проверок включает:

• проблемную страницу под разрешённой учётной записью;
• ту же страницу без входа;
• соседний публичный URL;
• закрытый служебный файл, который не должен раздаваться;
• журналы Nginx и приложения без новых ошибок.

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

Источники

• RFC 9110: статус 403 Forbidden
• Nginx: обработка запроса и выбор server
• Nginx: модуль ограничения доступа