Nginx: 403 Forbidden — directory index is forbidden

#Две разные причины одного кода

Сообщение directory index of ... is forbidden значит, что в каталоге нет файла из списка index, а автоиндекс (autoindex) выключен: nginx не имеет права показывать содержимое. Сообщение failed (13: Permission denied) — nginx нашёл файл или каталог, но у его пользователя нет прав доступа. Эти случаи различаются по записи в error.log, поэтому начните с чтения журнала и не меняйте права наугад.

#Возможные причины

#Порядок

1. Прочитайте запись в error.logНа сервере через SSH откройте журнал Nginx командой sudo tail -n 60 /var/log/nginx/error.log и повторите проблемный запрос. Если видите именно directory index of ... is forbidden, Nginx нашёл каталог, но не обнаружил разрешённый индексный файл. Если запись говорит Permission denied, это другой сценарий и нужно проверить права, а не индекс.
2. Если «directory index forbidden»: создайте индексный файл или включитеВ панели файлов сайта или по SSH проверьте наличие index.php/index.html именно в каталоге из лога. Если страница должна открывать PHP, проверьте также fastcgi_pass и обработчик .php. Не включайте autoindex on на корне публичного сайта: это позволяет посетителям просматривать список файлов. Включение листинга допускается только для специально опубликованного каталога без секретных данных.
3. Проверьте директиву indexВ конфигурации нужного блока server проверьте строку index index.php index.html; и фактический root с помощью sudo nginx -T. Если index.php существует, но Nginx не передаёт PHP-запрос в FPM, исправляйте только связанный блок location. Сохраните копию конфигурации, затем sudo nginx -t до применения.
4. Если «Permission denied»: определите пользователя nginxЕсли журнал указывает Permission denied, найдите пользователя рабочих процессов по ps -o user,cmd -C nginx или конфигурации user, затем выполните namei -l /реальный/путь/index.php. На каждом родительском каталоге нужны права прохода x, а на файле — чтения для нужной учётной записи или группы; не назначайте 777.
5. Проверьте права на каждый каталог пути: у пользователя nginx должно бытьПроверьте доступ к каталогам через безопасную команду namei -l и просмотрите ACL getfacl для проблемного пути, если инструмент установлен. Исправляйте только конкретный каталог/файл, для которого доказано отсутствие права, с учётом владельца и процессов PHP-FPM; массовое chmod -R может нарушить изоляцию виртуальных хостов.
6. Если сайт лежит в домашнем каталоге, добавьте право x на домашнюю папкуЕсли сайт лежит под /home/пользователь, проверьте права прохода на /home и домашнем каталоге; не делайте домашний каталог доступным всем ради сайта. Предпочтительнее отдельный корень сайта и доступ через ограниченную группу/ACL. Перед переносом сохраните конфигурацию и проверьте связанные пути загрузок и журналов.
7. Проверьте SELinux/AppArmorНа системах с SELinux прочитайте sudo ausearch -m AVC -ts recent и контексты ls -Z для реального пути, а на системах с AppArmor — соответствующие сообщения журнала. Исправляйте контекст по системной политике и только после подтверждения блокировки; отключать SELinux/AppArmor целиком не нужно.
8. Проверьте правила allow/deny в блокахНаконец проверьте у нужного location директивы deny, allow, auth_basic и внешние правила WAF. Выполните sudo nginx -t && sudo systemctl reload nginx; по curl -I https://ваш-сайт/ убедитесь, что нужный URL открывается и закрытые каталоги по-прежнему защищены.
9. Команды для отдельных ситуацийВыберите только подходящий вариант. Это не одна последовательность: часть команд диагностирует проблему, а часть меняет настройки или данные.
   Выберите подходящий вариант — это не команды для последовательного выполнения

   Вариант 1Пользователь nginx и права по всей цепочке каталогов

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

   Пользователь nginx и права по всей цепочке каталогов

   grep -E "^\s*user" /etc/nginx/nginx.conf

   namei -l /var/www/example.ru/public/index.html

   ps -o user,cmd -C nginx

   Вариант 2Исправить права: каталоги 755, файлы 644; владелец — пользователь сайта (путь замените)

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

   Исправить права: каталоги 755, файлы 644; владелец — пользователь сайта (путь замените)

   namei -l /var/www/example.ru/public/index.html

   # Меняйте права только для подтверждённо недоступного участка пути, не массово.

   Вариант 3Пример размещения index с выключенным листингом файлов; требуется адаптация к действующей конфигурации.

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

   Пример размещения index с выключенным листингом файлов; требуется адаптация к действующей конфигурации.

   server {

   root /var/www/example.ru/public;

   index index.php index.html;

   location /files/ {

   autoindex off; # не раскрывайте содержимое каталогов

   }

   }

   # Пример фрагмента: не подставляйте его целиком вместо действующего блока server.

   Вариант 4SELinux: контекст каталога сайта (RHEL/CentOS/AlmaLinux)

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

   SELinux: контекст каталога сайта (RHEL/CentOS/AlmaLinux)

   ls -Z /var/www/example.ru/public | head

   sudo ausearch -m AVC -ts recent

   # Корректируйте SELinux-контексты только после подтверждения отказа.

   Вариант 5Применить конфигурацию

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

   Применить конфигурацию

   sudo nginx -t && sudo systemctl reload nginx

#Проверка после правок

Выполните запрос с командной строки: curl -I https://example.ru/ должен вернуть 200. Если по-прежнему 403, посмотрите последнюю запись журнала: она всегда указывает точную причину. Отдельно проверьте, не перехватывает ли запрос другой блок server (команда nginx -T | grep server_name) и не включена ли в блоке защита от доступа к скрытым файлам (location ~ /\. { deny all; }), которая блокирует и нужные пути вроде /.well-known/.