Код 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.