Nginx: 403 Forbidden — доступ запрещён

#Что означает ошибка

Nginx отвечает 403, когда не может или не должен отдавать ресурс: в каталоге нет индексного файла и запрещён листинг, у пользователя nginx (www-data, nginx) нет прав на файлы, правило deny блокирует адрес, или защитный модуль (SELinux, AppArmor) запрещает доступ. Точная причина записана в error.log — смотрите его первым.

#Причины и решения

#Пошаговое решение

1. Посмотрите логПодключитесь к серверу по SSH и прочитайте последние сообщения sudo tail -n 40 /var/log/nginx/error.log (при другом расположении найдите директиву error_log в конфигурации). Воспроизведите 403 на конкретном URL и ищите directory index ... is forbidden, Permission denied или access forbidden by rule. Каждая фраза требует своего исправления — не начинайте с изменения всех прав файлов.
2. Проверьте корневой каталогНайдите виртуальный хост данного домена командой sudo nginx -T 2>/dev/null | grep -n -E "server_name|root |alias " и определите корневой каталог нужного блока server. Сравните путь с реальным расположением index.php/index.html через ls -l, учитывая, что alias работает иначе, чем root. Сначала сохраните файл конфигурации, исправляйте только неверный путь и выполняйте sudo nginx -t.
3. Проверьте индексЕсли журнал сообщает directory index ... forbidden, проверьте, существует ли стартовый файл в фактическом каталоге сайта и задана ли директива index index.php index.html; в нужном контексте. Для PHP также проверьте отдельную обработку .php через PHP-FPM. Не включайте autoindex on только ради обхода 403: это может раскрыть содержимое каталога посетителям.
4. Проверьте права по всему путиЕсли ошибка Permission denied, выполните namei -l /var/www/site/index.html, заменив путь реальным файлом, и проверьте разрешение прохода по каждому каталогу для пользователя Nginx. Установите нужного владельца только после выяснения, кто должен читать статический файл и кто обслуживает PHP. Не применяйте chown -R www-data или массовую установку 755/644: на нескольких сайтах или при ACL это может сломать безопасность.
5. Исправьте владельцаЕсли найден конкретный файл, который веб-сервер должен читать, сохраните текущие права командой stat /фактический/путь и изменяйте только его с учётом пользователя и группы службы. Для каталогов нужно право прохода x, для файлов — чтение r; запись на все файлы Nginx не нужна. После точечной правки откройте проблемный URL; при новой ошибке верните прежний владелец/режим.
6. Проверьте правилаОткройте актуальный блок location нужного сайта в конфигурации и проверьте директивы deny, allow, auth_basic и ограничения по IP. Если доступ закрыт намеренно, не снимайте защиту. Если правило ошибочно блокирует публичный путь, сохраните старое значение и исправьте только условие, связанное с этим URL. После sudo nginx -t примените reload и проверьте ответ из нужной сети.
7. Проверьте SELinuxНа RHEL/AlmaLinux/Rocky с SELinux выполните getenforce и при Enforcing найдите отказ доступа в журнале аудита (ausearch -m AVC -ts recent, если установлен auditd). Проверьте действующий контекст ls -Z и исправляйте его штатно через semanage fcontext и restorecon только для целевого каталога. Временный chcon -R часто теряется после восстановления контекстов; не выключайте SELinux.
8. Команды для отдельных ситуацийВыберите только подходящий вариант. Это не одна последовательность: часть команд диагностирует проблему, а часть меняет настройки или данные.
   Выберите подходящий вариант — это не команды для последовательного выполнения

   Вариант 1Диагностика прав и применения конфигурации.

   Linux · Терминал (Bash)С осторожностьюНужен sudoКопировать всёВыделить

   Диагностика прав и применения конфигурации.

   sudo tail -n 30 /var/log/nginx/error.log

   namei -l /var/www/site/index.html

   sudo nginx -t

   # Не меняйте владельца и режим всех файлов без анализа текущих прав и ACL.

   Команда может изменить состояние системы или её настройки. Проверьте параметры и последствия перед запуском.

   Вариант 2Типовой корректный блок server.

   NginxКопировать всёВыделить

   Типовой корректный блок server.

   server {
       listen 80;
       server_name example.com;
       root /var/www/site;
       index index.php index.html;
       location / {
           try_files $uri $uri/ =404;
       }
   }

9. Перезагрузите nginxПроверьте конфигурацию sudo nginx -t; при успехе выполните sudo systemctl reload nginx, затем в браузере откройте тот же URL. Ответ 200 или предусмотренный редирект означает, что проверяемый маршрут снова доступен. Если 403 сохраняется, сопоставьте новое сообщение журнала со старым; не повторяйте изменения прав без дополнительной диагностики.

Если сайт расположен в домашнем каталоге с правами 700 (/home/user/site), Nginx может не иметь права прохода по родительскому каталогу. Не открывайте домашний каталог всем командой chmod o+x /home/user. Безопаснее перенести открытые файлы сайта в отдельный каталог публикации или выделить доступ только рабочей группе/учётной записи Nginx с помощью настроенных ACL. Сначала выясните фактического пользователя Nginx и права каждого каталога командой namei -l /реальный/путь/index.php. Для PHP-FPM отдельно проверьте доступ к сокету. При использовании Docker-томов сверяйте права и пользователей внутри контейнера. Документация — nginx.org.

Если сайт работает через PHP-FPM и 403 возникает только на .php, проверьте директиву location ~ \.php$ и права на сокет /run/php/php8.2-fpm.sock (пользователь www-data должен входить в группу сокета). В журнале ошибок внимательно читайте формулировку: «access forbidden by rule» означает правило deny, «directory index ... is forbidden» — отсутствие индекса, а «Permission denied» — права файловой системы или SELinux. После любых правок выполняйте sudo nginx -t, чтобы не остановить рабочий сайт ошибкой конфигурации.