Ошибка 403 Forbidden на сайте: причины и как вернуть доступ

403 означает, что сервер понял запрос и отказал в доступе. В девяти случаях из десяти причина в правах на файлы, в лишней строке .htaccess или в фаерволе хостинга, а не во взломе. Диагностику ведут от быстрого к долгому: сначала весь сайт или одна страница.

Ошибка 403 Forbidden на сайте пугает сильнее, чем заслуживает. Белая страница с надписью «Forbidden. You don’t have permission to access this resource» выглядит как взлом, а в девяти случаях из десяти это криво выставленные права на файлы, лишняя строка в .htaccess или фаервол хостинга, который принял вас за бота. Статья для владельцев сайтов на WordPress, Битриксе, OpenCart и MODX, которые открыли свой сайт и увидели запрет доступа. Разберём, откуда 403 берётся, как за пятнадцать минут понять причину и что делать, если доступа к панели хостинга у вас нет.

Я вожусь с чужими сайтами шесть лет, и 403 стабильно входит в тройку самых частых обращений вместе с белым экраном и «почта перестала приходить». Разница в том, что 403 почти всегда чинится быстро, если не начинать с паники и не выставлять 777 на всё подряд.

Что означает 403 и чем он отличается от 401 и 404

403 Forbidden означает буквально следующее: сервер понял запрос, нашёл ресурс и отказался его отдавать. Не «не нашёл», не «нужен пароль», а «нашёл, но не покажу».

Три соседних кода путают постоянно, хотя разница принципиальная для диагностики:

Код	Что говорит сервер	Типичная причина
401 Unauthorized	Нужна авторизация, покажи логин и пароль	Basic-авторизация на staging, защита папки паролем
403 Forbidden	Доступ запрещён, авторизация не поможет	Права на файлы, правила в .htaccess, фаервол, бан по IP
404 Not Found	Такого адреса нет	Битая ссылка, удалённая страница, сломанные ЧПУ
503 Service Unavailable	Сервер жив, но обслуживать не готов	Режим обслуживания, перегруз, лимиты хостинга

Практический вывод: если браузер показывает 403, вводить логины бессмысленно. Отдаёт запрет не CMS, а веб-сервер (Apache, nginx, LiteSpeed) или прослойка перед ним. WordPress и Битрикс к этому моменту чаще всего вообще не запускались.

Отдельно отмечу: 403 иногда приходит с телом страницы от самой CMS. Например, WordPress отдаёт свою страницу «Извините, вам не разрешён доступ к этой странице» с кодом 403. Это уже не веб-сервер, а логика прав пользователя, и лечится совсем иначе. Отличить просто: если дизайн страницы с ошибкой похож на ваш сайт или на админку, работает PHP, значит виноват код. Если голая надпись на белом фоне шрифтом Times, отвечает Apache.

Первым делом: 403 везде или точечно

Прежде чем лезть в файлы, потратьте две минуты и определите границы проблемы. Это сэкономит час.

Проверьте четыре адреса подряд:

1. Главную страницу сайта.
2. Любую внутреннюю страницу (например /kontakty/).
3. Статический файл напрямую: /wp-content/themes/ваша-тема/style.css или любую картинку из галереи.
4. Вход в админку: /wp-admin/, /bitrix/admin/, /admin/.

Дальше смотрите на картину:

• 403 на всём, включая картинки, значит проблема на уровне корневой папки: права, .htaccess в корне, фаервол или блокировка вашего IP.
• Главная открывается, внутренние страницы отдают 403, значит дело в правилах ЧПУ или в модуле безопасности, который режет часть URL.
• Сайт работает, 403 только на админке, значит кто-то (вы, подрядчик или плагин) закрыл её по IP или по паролю.
• 403 только у вас, а с телефона по мобильному интернету всё открывается, значит забанен ваш IP. Это самый частый сценарий и самый безобидный.

Последний пункт проверяется буквально за десять секунд: выключите Wi-Fi на телефоне и откройте сайт по мобильной сети. Ещё надёжнее посмотреть заголовки ответа из командной строки:

# Смотрим только заголовки ответа, без тела страницы
curl -sSI https://example.ru/ | head -20

# Тот же запрос, но представляемся обычным браузером
curl -sSI -A "Mozilla/5.0 (Windows NT 10.0; Win64; x64)" https://example.ru/

# Проверяем конкретный статический файл
curl -sSI https://example.ru/wp-content/uploads/2026/01/photo.jpg

Если с дефолтным user-agent приходит 403, а с браузерным 200, значит вас режет защита от ботов. Это не поломка сайта, это настройка. Заодно посмотрите в заголовках Server и нестандартные поля вроде X-Firewall или X-Sucuri-ID: они часто выдают виновника прямо в ответе.

Права на файлы и папки: 644 и 755

Классика. Сайт переехал на новый хостинг, разработчик залил архив по FTP, распаковал, и часть файлов получила права 600 или 640. Apache работает от имени пользователя веб-сервера, в файл заглянуть не может и отвечает 403.

Рабочая схема прав на shared-хостинге выглядит так:

• файлы: 644 (владелец читает и пишет, остальные только читают),
• папки: 755 (владелец делает всё, остальные читают и заходят внутрь),
• wp-config.php и bitrix/php_interface/dbconn.php: 600 или 640, если хостинг это позволяет,
• папки с загрузками (wp-content/uploads, upload/): те же 755, писать должен уметь владелец, а не «все».

Массово починить права можно одной парой команд по SSH:

cd ~/example.ru/public_html

# Папкам 755
find . -type d -exec chmod 755 {} ;

# Файлам 644
find . -type f -exec chmod 644 {} ;

# Проверяем, что осталось с нестандартными правами
find . ( -type f -not -perm 644 ) -o ( -type d -not -perm 755 ) | head -50

Если SSH нет, те же права выставляются в файловом менеджере панели хостинга рекурсивно: выделяете корень, «Изменить права», ставите 755 с галкой «применить к папкам», потом 644 с галкой «применить к файлам». В ISPmanager и в панели Timeweb это делается в два клика.

Теперь про 777, потому что этот совет до сих пор гуляет по форумам. Права 777 означают, что писать в файл может любой процесс на сервере, включая чужой сайт соседа по shared-хостингу. На нормальном хостинге с изоляцией это просто плохо, на дешёвом это готовый вектор заражения. Больше того, часть хостеров (и почти все с mod_ruid2 или suexec) сами отдают 403 на файлы с правами 777, считая их небезопасными. То есть вы поставили 777, чтобы починить 403, и получили ровно тот же 403. Подробнее про модель прав я разбирал в отдельной статье про права на файлы 644 и 755, там же про владельца файлов и про то, почему после распаковки архива через панель владельцем иногда становится не тот пользователь.

Кстати про владельца. Если права выглядят правильно, а 403 остался, смотрите на владельца:

ls -la ~/example.ru/public_html | head -20
# Все файлы должны принадлежать вашему пользователю хостинга,
# а не root и не www-data

Файлы, принадлежащие root, поправить из панели не выйдет, нужна заявка в поддержку хостинга. Формулировка для тикета простая: «После распаковки архива часть файлов принадлежит root, сайт отдаёт 403. Прошу сменить владельца на пользователя cr43080 рекурсивно по каталогу public_html.»

Нет индексного файла и запрещён листинг

Второй по частоте сценарий, особенно на подпапках и на свежих доменах. Вы открываете https://example.ru/, а в корне нет ни index.php, ни index.html. Apache в этом случае должен показать список файлов, но листинг директорий на большинстве хостингов выключен директивой Options -Indexes. Показывать нечего, отдавать нечего, ответ 403.

Проверяется за минуту: зайдите в корень сайта файловым менеджером и убедитесь, что index.php на месте. Частые причины пропажи:

• сайт залили не в ту папку (в public_html/example.ru/ вместо public_html/),
• домен в панели хостинга смотрит на другую директорию,
• антивирус хостинга унёс index.php в карантин, посчитав его заражённым (бывает после реального взлома, и тогда чинить нужно не 403),
• в .htaccess затёрлась директива DirectoryIndex.

Если файл на месте, но не подхватывается, добавьте в .htaccess в корне явное указание:

DirectoryIndex index.php index.html

И отдельно про листинг: если 403 вылезает при заходе в служебную папку вроде /wp-content/uploads/2026/, это нормально и трогать не надо. Открытый листинг загрузок это подарок парсерам и сборщикам баз, пусть он остаётся закрытым.

Правила в .htaccess

Самая интересная часть, потому что здесь 403 обычно поставили специально, просто забыли об этом.

Откройте .htaccess в корне и в подпапках (в WordPress их часто два или три: корень, wp-admin, wp-content/uploads). Ищите блоки такого вида:

# Старый синтаксис Apache 2.2
Order allow,deny
Deny from all

# Новый синтаксис Apache 2.4
Require all denied

# Точечный бан по адресу
Deny from 178.45.0.0/16

# Блокировка по user-agent
RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} (AhrefsBot|SemrushBot|MJ12bot) [NC]
RewriteRule ^ - [F,L]

# Защита админки по IP
<Files wp-login.php>
  Require ip 95.123.45.67
</Files>

Каждая из этих конструкций отдаёт ровно 403. Типовые ситуации, которые я вижу в работе:

• Флаг [F] в правиле RewriteRule. Это и есть Forbidden. Правило писалось против парсеров, а под шаблон случайно попали живые страницы.
• Блок Require ip вокруг wp-login.php, поставленный подрядчиком со своего домашнего IP. У провайдера сменился динамический адрес, и в админку не заходит уже никто, включая автора правила. Если вы приехали сюда за защитой входа, лучше делать её нормально, через ограничение попыток и второй фактор: писал об этом в статье про ограничение попыток входа в админку.
• Смешанный синтаксис 2.2 и 2.4 в одном файле. После апгрейда Apache на хостинге старые директивы Order allow,deny перестают работать предсказуемо, и доступ рубится целиком.
• Правила против ботов, скопированные с форума пачкой на сто строк. Половина из них ловит нормальные краулеры Яндекса и Google, и потом сайт вылетает из индекса. Осмысленный набор правил я собирал в материале про htaccess против ботов и парсеров.

Методика проверки простая и грубая: переименуйте .htaccess в .htaccess.bak и обновите страницу.

mv .htaccess .htaccess.bak
curl -sSI https://example.ru/ | head -3

Если 403 исчез (даже если вместо него появился 404 на внутренних страницах, это нормально, у WordPress без .htaccess отваливаются ЧПУ), причина найдена. Дальше возвращаете файл и режете его пополам, комментируя блоки решёткой, пока не найдёте виновную строку. На это уходит минут пять.

Важная оговорка для nginx. Если хостинг работает на чистом nginx без Apache, файл .htaccess не читается вообще, и все правила лежат в конфиге сервера, куда у вас доступа нет. Тогда причину 403 придётся выяснять через поддержку. Понять, что у вас за сервер, можно по заголовку Server в выводе curl из предыдущего раздела.

Фаервол хостинга и плагины безопасности

Третий источник 403 живёт выше уровня сайта, и его сложнее всего заметить, потому что в файлах сайта ничего подозрительного нет.

ModSecurity. Стоит почти на всех российских shared-хостингах. Набор правил, который режет запросы по сигнатурам. Отдаёт 403 и пишет в лог сайта строку с идентификатором правила. Ложные срабатывания случаются регулярно: на длинных текстах в редакторе, на загрузке файлов с необычным содержимым, на POST-запросах с кодом внутри. Симптом характерный: страницы открываются, а сохранение записи или отправка формы отваливается в 403.

Лечится обращением в поддержку с просьбой отключить конкретное правило для вашего сайта. Найти номер правила можно в логах:

# Логи Apache в домашней директории (путь зависит от хостинга)
grep -i "mod_security|ModSecurity" ~/logs/example.ru.error.log | tail -20

# Или ищем все 403 в access-логе за сегодня
grep " 403 " ~/logs/example.ru.access.log | tail -30

Плагины безопасности CMS. Wordfence, iThemes Security, Limit Login Attempts, в Битриксе штатный «Проактивная защита». Все они умеют банить IP после серии неудачных входов, после срабатывания на подозрительный запрос или просто по географии. Себя забанить проще, чем кажется: три опечатки в пароле, и вы в чёрном списке на сутки.

Если админка закрыта собственным плагином, снимать бан придётся из базы или через отключение плагина по FTP:

# Отключаем плагин, переименовав его папку
mv wp-content/plugins/wordfence wp-content/plugins/wordfence-off

WordPress увидит, что файл плагина пропал, и деактивирует его сам, не сломав остальное. После входа в админку возвращаете папку обратно и чистите чёрный список изнутри.

Внешние фаерволы и CDN. Если перед сайтом стоит защитный прокси, 403 может отдавать он, а не ваш сервер. Опознаётся по нестандартной странице с номером инцидента и по заголовкам ответа.

Блокировка на стороне хостинга целиком. Бывает, когда сайт словил вирус и хостер закрыл его до устранения. Обычно об этом приходит письмо, но письмо любят пропускать. Если 403 отдаётся на всё, включая статику, а в файлах и .htaccess чисто, откройте панель хостинга и почитайте уведомления. Заодно проверьте, не закончился ли оплаченный период.

Частные случаи, которые выглядят иначе

403 только на загрузке файлов. Медиатека WordPress пишет «Извините, вам не разрешено загружать файлы этого типа» или запрос падает в 403. Смотрите права на wp-content/uploads (должно быть 755 и правильный владелец) и на ModSecurity, который часто режет multipart-запросы.

403 при сохранении записи в редакторе. Почти всегда ModSecurity или фаервол, сработавший на HTML-код внутри текста. Проверяется просто: сохраните запись из двух слов без разметки. Сохранилась, значит дело в содержимом.

403 на REST API. Адрес /wp-json/wp/v2/posts отдаёт запрет, из-за чего ломается Gutenberg и часть плагинов. Обычно это правило безопасности, закрывающее REST от анонимов. Отключать целиком не надо, достаточно разрешить авторизованные запросы.

403 на картинках при живом сайте. Проверьте хотлинк-защиту в .htaccess. Правило с RewriteCond %{HTTP_REFERER} и флагом [F] защищает картинки от воровства, но при смене домена или при переходе на HTTPS начинает резать собственный сайт.

403 сразу после переезда. Классика при смене хостинга: архив распаковали, права слетели, .htaccess от старого сервера тянет директивы, которых новый Apache не понимает. Порядок действий тот же: права, потом .htaccess, потом логи.

Порядок диагностики от быстрого к долгому

Чек-лист, по которому я иду сам. Каждый шаг занимает меньше времени, чем предыдущий давал информации, и в 90 процентах случаев ответ находится на первых четырёх пунктах.

1. Открыть сайт с телефона по мобильной сети. Работает, значит забанен ваш IP, дальше искать бан.
2. Дёрнуть curl -I с браузерным user-agent и без него. Разница в ответе указывает на защиту от ботов.
3. Проверить, отдаётся ли 403 на статический файл. Если да, проблема ниже уровня CMS.
4. Переименовать .htaccess и обновить страницу. Помогло, значит виноват он.
5. Посмотреть права и владельца на корень сайта и на index.php.
6. Открыть error_log и access_log за сегодня, поискать записи ModSecurity и строки со статусом 403.
7. Отключить плагины безопасности переименованием папок.
8. Проверить уведомления и баланс в панели хостинга.
9. Написать в поддержку хостинга: «Сайт example.ru отдаёт 403 на все запросы с IP 95.x.x.x с 14:20 МСК. Права 644/755 выставлены, .htaccess временно отключён, в логах записей ModSecurity нет. Прошу проверить блокировки на стороне сервера.»

Отдельно про то, чего делать не надо. Не ставьте 777, не удаляйте .htaccess навсегда вместо разбора (потеряете ЧПУ и правила кэша), не сносите плагин безопасности целиком, если не понимаете, что он защищал. И не путайте 403 с белым экраном: белый экран без кода ошибки это уже PHP, и лечится он совсем по-другому.

Как не встречаться с этим снова

403 почти всегда рукотворный. Его ставит человек, который что-то настраивал, или автоматика, которую этот человек включил. Поэтому профилактика скучная, но работает:

• Держать копию рабочего .htaccess отдельно от сайта, с датой в имени. При правках сначала копия, потом изменение.
• Записывать в паспорт сайта, какие защитные правила стоят и почему. Через полгода вы не вспомните, зачем закрывали xmlrpc.php.
• Не привязывать доступ в админку к домашнему IP, если он динамический. Это мина замедленного действия.
• Проверять сайт мониторингом, который умеет отличать 403 от 200. Пинг главной по факту наличия ответа тут бесполезен: сервер жив, страница отдаётся, только это страница с запретом.
• После любого переезда прогонять массовое выставление прав и открывать не только главную, но и внутреннюю страницу с картинкой.

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

Если сайт лежит с 403 прямо сейчас и разбираться некогда, напишите через форму на главной и приложите три вещи: адрес сайта, что делали перед появлением ошибки и доступы к панели хостинга. Обычно этого хватает, чтобы вернуть сайт в течение часа. Другие разборы типовых аварий собраны в рубрике про поддержку.

Частые вопросы

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

Сервер получил запрос, понял его и отказался отдавать содержимое. Это не отсутствие страницы и не требование авторизации, а именно запрет доступа.

С чего начинать диагностику

Проверить, 403 везде или на одной странице. Если везде, смотрят права на корневую папку и .htaccess. Если точечно, ищут правило, которое ловит именно этот адрес.

Какие права должны быть у файлов

Обычно 644 для файлов и 755 для папок. Права 777 не решают проблему, а создают новую: на многих хостингах сервер отказывается отдавать файлы с такими правами.

Может ли 403 быть от фаервола хостинга

Может, и это частый случай. Фаервол блокирует адрес по подозрительной активности или по стране. Проверяется обращением в поддержку и просмотром своих правил безопасности.