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

Автор: Редакция Торох Опубликовано: 14 ноября 2026 8 минут чтения

403 Forbidden — ответ сервера, которым он отказывает в доступе к существующей странице или файлу. Учётные данные и повторный вход делу не помогут: запрет задан правилами на стороне сервера, в правах на файлы, в конфигурации веб-сервера или в модуле безопасности. Посетителю остаётся проверить ссылку, VPN и расширения, владельцу сайта — разобрать логи и настройки доступа.

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

403 Forbidden — стандартный код ответа HTTP. Им сервер сообщает: запрос получен, адрес существует, но отдавать содержимое сервер не будет. Слово Forbidden переводится как «запрещено», и это точная формулировка — доступ закрыт правилом, а не потерян.

Отсюда практический вывод: повторная отправка формы, вход в аккаунт и очистка кеша обычно ничего не меняют. Решение уже принято — на уровне веб-сервера, модуля безопасности, файрвола или настроек каталога — и оно не зависит от того, насколько аккуратно вы ввели пароль.

В браузере ошибка выглядит по-разному. Chrome и Firefox показывают свою заглушку с надписью «403 Forbidden» или «Доступ запрещён». nginx отдаёт простую белую страницу с крупным «403 Forbidden» и подписью вида nginx/1.x.x внизу. Apache выводит «Forbidden. You don't have permission to access this resource». Многие сайты подменяют стандартный ответ собственной страницей с меню и ссылкой на главную — внешне она похожа на обычную, но нужного материала на ней нет, а адрес в строке браузера остаётся прежним.

Чем отличается от похожих кодов

Разница между 401 и 403 — ключевая при диагностике. Если сервер хотел бы получить логин и пароль, он отвечает 401 и предлагает аутентификацию. Код 403 означает, что даже с правильными данными доступ останется закрытым: запрет задан для файла, каталога, IP-адреса, страны или типа запроса.

С 404 ошибку 403 роднит только неудобство для посетителя. Иногда администраторы намеренно отдают 403 вместо 404 на скрытые разделы, чтобы не подтверждать существование файла. От 429 код отличается природой ограничения: там мешает частота обращений, здесь — сами права. Близкий случай — 503 Service Unavailable, когда сервер временно не может обслуживать запросы.

Причины

Для посетителя

• Ссылка ведёт на каталог или файл, закрытый администратором: архивы резервных копий, служебные скрипты, страницы «только для своих».
• Сайт ограничивает доступ по IP-адресу или стране. Частая причина — включённый VPN с зарубежным адресом либо, наоборот, попытка открыть зарубежный сервис из России.
• Сработала защита от ботов: слишком частые запросы, нетипичный user-agent, отключённые cookies, блокировщик рекламы и скриптов.
• Требуется вход в аккаунт, платная подписка или подтверждение возраста.
• Материал перенесён, старая ссылка осталась, и сервер отвечает 403 вместо 404 из-за настроек каталога.
• Ошибка на стороне сервиса. Если 403 появляется не в браузере, а внутри приложения — при оплате в магазине мобильной игры, в клиенте для синхронизации телефона с компьютером, в фотосервисе, — влиять из браузера почти нельзя: проверяют регион и VPN, обновляют приложение и обращаются в поддержку.

Для владельца сайта или разработчика

• Неверные права доступа: чтение закрыто для пользователя, от имени которого работает веб-сервер.
• В конфигурации прописан явный запрет: deny all, Require all denied, Options -Indexes вместе с отсутствием индексного файла.
• В каталоге нет индексного файла (index.html, index.php), а листинг запрещён — nginx и Apache возвращают 403 на запрос каталога.
• Срабатывает WAF или антибот: ModSecurity, правила CDN, плагин безопасности CMS.
• Блокировка по IP, диапазону адресов или географии в файрволе, на прокси или в панели CDN.
• Ошибка в правилах переписывания URL: try_files указывает на несуществующий путь и заканчивается принудительным =403.
• Ограничения в самом приложении: маршрут закрыт middleware, статика отдаётся с параметром dotfiles: 'deny', отказала авторизация на уровне кода.

Что делать посетителю

1. Обновить страницу с очисткой кеша (Ctrl+F5 или Cmd+Shift+R) и проверить адрес: нет ли опечатки, лишнего слэша, устаревшей ссылки.
2. Открыть тот же адрес в другом браузере и в режиме инкогнито — так исключаются расширения и кеш.
3. Отключить VPN и прокси, проверить, не включён ли режим экономии трафика.
4. Разрешить для сайта cookies и отключить блокировщик рекламы.
5. Войти в аккаунт, если материал предназначен подписчикам.
6. Зайти на главную и найти материал через меню или поиск по сайту.
7. Если ошибка возникла внутри приложения или магазина, обновить его, перезайти в аккаунт и написать в поддержку сервиса.

Что делать владельцу сайта: пошаговая диагностика

Начинайте с логов: они почти всегда называют конкретную причину. Дальше проверяйте звенья цепочки по порядку — права, веб-сервер, приложение, внешние фильтры.

Шаг 1. Найти запрос в логах

tail -n 200 /var/log/nginx/access.log | grep ' 403 '
tail -n 200 /var/log/nginx/error.log

В access.log код ответа стоит в предпоследнем поле строки. В error.log nginx пишет причину прямым текстом: directory index of "/var/www/site/" is forbidden, access forbidden by rule или сообщение от ModSecurity с идентификатором правила. Для Apache логи лежат в /var/log/apache2/ или /var/log/httpd/.

Шаг 2. Проверить права на файлы и каталоги

namei -l /var/www/site/wp-content/uploads/foto.jpg
find /var/www/site -type d ! -perm -755 -ls
find /var/www/site -type f ! -perm -644 -ls
chown -R www-data:www-data /var/www/site

Файлы — 644, каталоги — 755, владелец — пользователь веб-сервера (www-data, apache, nginx). Права 777 не решение: они открывают запись всем. Учтите, что файлы, созданные скриптом от другого пользователя, могут оказаться недоступны веб-серверу после обновления или восстановления из резервной копии.

Шаг 3. Проверить конфигурацию nginx

nginx -T | grep -n -E 'deny|allow|auth_basic|try_files|autoindex'

Типовая ошибка — правила, закрывающие служебные пути, задевают и рабочие адреса. Рабочая конфигурация для сайта на PHP-FPM выглядит примерно так:

server {
    listen 80;
    server_name example.com;
    root /var/www/site;
    index index.html index.php;

    location / {
        try_files $uri $uri/ /index.php?$args;
    }

    location ~ \.php$ {
        include fastcgi_params;
        fastcgi_pass unix:/run/php/php-fpm.sock;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    }
}

Если в каталоге нет индексного файла, а autoindex off, запрос каталога даст 403 — добавьте индексный файл или разрешите листинг только там, где он действительно нужен.

Шаг 4. Проверить Apache и .htaccess

apachectl -S
apachectl configtest

В Apache 2.4 доступ по умолчанию запрещён, пока не разрешён явно:

<Directory /var/www/site>
    Options -Indexes +FollowSymLinks
    AllowOverride All
    Require all granted
</Directory>

Проверьте .htaccess: правила плагинов безопасности, deny from all, ограничения по IP. Базовый набор правил WordPress без лишних комментариев выглядит так:

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>

Шаг 5. Проверить PHP-FPM

В error.log ищите строку Access to the script has been denied (see security.limit_extensions) — это 403 от PHP-FPM. Причина обычно в директиве security.limit_extensions или в том, что SCRIPT_FILENAME указывает на несуществующий файл. Права на unix-сокет (listen.owner, listen.group, listen.mode) и пользователь в fastcgi_pass должны совпадать с теми, под которыми работает nginx; рассогласование чаще даёт 502, но встречается и в связке с 403.

Шаг 6. WordPress и другие CMS

wp plugin list --status=active
wp option get siteurl
curl -I https://example.com/wp-login.php

Отключайте плагины безопасности по одному, чтобы найти виновника. Проверьте права на wp-content/uploads и wp-config.php, а также не осталось ли в .htaccess правил от удалённого плагина. После обновления CMS всегда проверяйте главную, страницу записи и админку.

Шаг 7. Node.js и другие приложения

В Express статика по умолчанию закрывает файлы, начинающиеся с точки, а dotfiles: 'deny' усиливает запрет. Проверьте middleware, которые возвращают res.status(403), и настройки обратного прокси:

app.use(express.static(path.join(__dirname, 'public'), {
  index: 'index.html',
  dotfiles: 'deny'
}));

Логи приложения (morgan, pino) показывают, на каком маршруте возник отказ. Для фреймворков с политикой доступа проверьте роли пользователя и правила авторизации.

Шаг 8. Проверить WAF, CDN и блокировки

curl -I https://example.com/page
curl -I -A "Mozilla/5.0" https://example.com/page
iptables -L -n | head -50

Если с локального адреса ответ 200, а снаружи 403, причина во внешнем фильтре: правило файрвола в панели CDN, блокировка страны, fail2ban или ModSecurity. На время диагностики переведите WAF в режим обнаружения (SecRuleEngine DetectionOnly) и верните защиту, когда причина найдена. Отдельно убедитесь, что поисковые роботы не получают 403: проверьте robots.txt и при необходимости соберите файл заново через генератор robots.txt.

Как предотвратить повторение

• Настройте мониторинг доступности с контролем кодов ответа: отслеживайте не только недоступность сайта, но и долю ответов 403 по ключевым страницам.
• Заведите оповещение о всплеске 403 в логах: резкий рост обычно означает, что новое правило WAF или обновление плагина закрыло рабочий раздел.
• Храните конфигурацию веб-сервера и .htaccess в системе контроля версий — тогда причину правки легко найти и откатить.
• Используйте ограничение частоты запросов вместо полной блокировки: limit_req в nginx, правила CDN, fail2ban с белым списком для поисковых роботов и платёжных сервисов.
• Проверяйте изменения на тестовом стенде с теми же правами и конфигурацией, что на рабочем сервере, и прогоняйте после обновлений короткий список страниц.
• Держите под рукой короткую памятку по умолчанию: файлы 644, каталоги 755, индексные файлы на месте, листинг каталогов закрыт.

Материал подготовлен редакцией справочника Торох и носит справочный характер: интерфейсы программ и настройки серверов зависят от версии. Нашли неточность? Напишите нам.