Код 403 Forbidden в ответе nginx означает, что сервер понял запрос, но отказался его выполнять — в отличие от 404, файл или маршрут найден, но доступ к нему закрыт. Разбор ниже рассчитан на администратора, который увидел 403 в браузере или в логах и хочет быстро найти причину, не перебирая директивы наугад.
Что означает код 403 в логах nginx
В access.log запись с кодом 403 появляется там же, где и остальные запросы, но сам nginx не всегда объясняет причину в этой строке — для подробностей нужно смотреть error.log, где обычно указан конкретный файл или директива, на которой произошёл отказ.
403 отличается от 401: у 401 браузер покажет запрос логина и пароля, у 403 — просто отказ без запроса авторизации. Это разные механизмы, и путать их при диагностике не стоит.
Самая частая причина — index не найден и autoindex выключен
Если в location нет файла, указанного в директиве index — обычно index.html или index.php, — а директива autoindex выключена (значение по умолчанию off), nginx возвращает 403 вместо списка файлов каталога. Это защитное поведение, а не ошибка конфигурации.
Проверяется просто: наличие нужного файла в корне location и значение index в конфиге. Базовые принципы настройки описаны в статье про настройку nginx.
Права доступа к файлам и каталогам
Процесс nginx работает от отдельного пользователя — чаще всего www-data или nginx, — и этому пользователю нужны права на чтение файла и на выполнение (не чтение!) каждого каталога в пути к нему. Это частая причина 403: файл читаем, но один из родительских каталогов закрыт для чужих.
| Элемент | Нужное право | Частая ошибка |
|---|---|---|
| Файл в корне сайта | чтение для владельца процесса | права 600 только для другого пользователя |
| Каталог сайта | выполнение для прохода | права 700 без group и other |
| Домашний каталог пользователя | выполнение для группы или other | права 750 закрывают доступ nginx |
| Загруженные файлы | чтение после загрузки скриптом | файл создан с правами 600 |
| Сокет PHP-FPM | доступ группы nginx | сокет принадлежит только php-fpm |
Директивы allow и deny и ограничение по IP
Директивы allow и deny ограничивают доступ по адресу клиента и часто остаются в конфиге после временной блокировки — например, администратор закрыл доступ на период работ и забыл снять ограничение.
Правила читаются по порядку сверху вниз, и неявное deny all в конце блока — обычная причина, когда конкретный IP не попал ни в одно разрешающее правило. Похожие ограничения разбираются в статье про усиление защиты nginx, где описано, как не закрыть доступ самому себе.
Конфликт конфигурации между несколькими location
Когда для одного пути подходят два блока location, nginx выбирает по правилам приоритета — точное совпадение, затем префиксное с наибольшей длиной, затем регулярное выражение. Если более широкий блок случайно содержит запрещающую директиву, она перекрывает более специфичный блок, который должен был сработать.
Диагностировать такие конфликты проще всего, читая полную развёрнутую конфигурацию, а не отдельный файл: подключённые директивы include превращают простую на вид настройку в несколько уровней вложенности.
Как найти причину и исправить
Порядок диагностики, который закрывает большинство случаев:
- посмотреть точную строку в error.log — там указан файл или директива, вызвавшая отказ;
- проверить права на файл и на каждый каталог в пути командой namei -l;
- свериться с развёрнутым конфигом через nginx -T, чтобы увидеть все include разом;
- временно убрать директивы allow и deny и проверить, пропадает ли ошибка;
- перезагрузить конфигурацию командой nginx -s reload после правки и проверить запрос снова.
sudo tail -n 20 /var/log/nginx/error.log
sudo namei -l /var/www/site/public/index.htmlsudo nginx -t
sudo nginx -s reloadПосле устранения причины имеет смысл проверить, не влияют ли настройки буферов и кеша на похожие ошибки при росте нагрузки — это рассмотрено в статье про оптимизацию nginx на VPS.
Частые вопросы
Чем 403 отличается от 404 в ответе nginx?
404 означает, что сервер не нашёл ресурс по указанному пути вовсе. 403 означает обратное: ресурс существует, но сервер намеренно отказывает в доступе — из-за прав на файл, директив allow и deny или отсутствия индексного файла при выключенном autoindex.
Почему 403 возникает, если сам файл читаем, но каталог выше закрыт?
Для прохода через каталог процессу нужно право на выполнение, а не на чтение. Если у одного из родительских каталогов в пути нет этого права для пользователя, от которого работает nginx, сервер не сможет дойти до файла, даже если права на сам файл верные.
Нужно ли включать autoindex, чтобы избавиться от 403?
Не обязательно и чаще всего не стоит: autoindex открывает список файлов каталога всем посетителям, что само по себе риск для приватных данных. Правильнее добавить недостающий index-файл или явно указать нужный путь в location.
Может ли 403 появляться из-за SELinux, а не из-за самого nginx?
Да, на системах с включённым SELinux контекст файла проверяется отдельно от обычных прав Linux: даже верные права чтения не помогут, если метка контекста не разрешает доступ процессу nginx. В таком случае отказ виден в логе аудита SELinux, а не только в error.log nginx.