Apache LinuxApache HTTP Server 2.4

Apache: ошибка 403 после смены DocumentRoot, хотя PHP работает

  • Обновлено
  • Чтение ≈ 4 минуты
  • Нужны права администратора

Краткий ответ

Apache возвращает 403 после переноса DocumentRoot: как отличить отсутствие доступа к каталогу, неверный DirectoryIndex и запрет в конфигурации.

В этой статье
  1. Что означает проблема
  2. Как различить причины
  3. Подробная диагностика и устранение
  4. Как проверить результат
  5. Если проблема не устранена

#Что означает проблема

Код 403 Forbidden после смены DocumentRoot не доказывает неисправность PHP: сам модуль или PHP-FPM могут работать, а Apache отказывает в доступе к конкретной папке или не находит разрешённый индексный файл. Если прямой адрес /index.php открывается, а главная страница нет, проверьте DirectoryIndex и Options -Indexes.

#Как различить причины

Возможная причинаКак узнатьЧто делать
Запрещён новый путьДля нового DocumentRoot не задан подходящий блок Directory с Require all granted.В error.log присутствуют сообщения об отказе в авторизации.Ограниченно разрешить публичный каталог в правильном VirtualHost.
Нет индекса, листинг выключенЗапрос / попадает в папку без распознаваемого DirectoryIndex.Прямой /index.php работает, главная отдаёт 403 с сообщением об отсутствии индекса.Проверить, где лежит index.php, и настроить DirectoryIndex при необходимости.
Нет прохода или запрещает политика ОСУ пользователя Apache нет права x на родительский каталог, SELinux/AppArmor блокирует чтение.В error.log ошибка permission denied, файловая система не позволяет доступ.Точечно исправить доступ, не применять chmod 777.

#Подробная диагностика и устранение

  1. Сравните главную страницу с проверенным файломВ браузере откройте https://example.com/, затем существующий и заведомо публичный /index.php, если он предусмотрен архитектурой сайта. Запишите коды и время. Если PHP-файл недоступен по адресу или отдаёт исходный код, остановитесь: второе означает риск раскрытия секретов и требует немедленно закрыть публичный доступ до исправления обработчика.
  2. Определите VirtualHost и каталогВ SSH на сервере выполните sudo apache2ctl -S, найдите домен и конфигурационный файл, откройте строку DocumentRoot. Проверьте наличие индекса командой sudo ls -la /путь/из/DocumentRoot/, заменив путь реальным. Не создавайте автоматически пустой index.php: это может скрыть неверную конфигурацию развёртывания.
  3. Читайте конкретную причину в журналеНа Debian/Ubuntu обычно используйте sudo tail -n 80 /var/log/apache2/error.log, но если у виртуального хоста собственный ErrorLog, откройте его. Ищите запись на время вашего теста: client denied by server configuration, Permission denied, Directory index forbidden. По этим фразам выбирайте разные действия, не устраняйте все причины одновременно.
  4. Исправьте доступ только к документам сайтаЕсли отказ вызван отсутствием подходящего правила, после копии файла настройте блок <Directory "/фактический/public"> Require all granted ... </Directory> исключительно для публичной папки. Убедитесь, что в неё не попали .env, резервные копии и файлы базы. Для приватных каталогов остаётся Require all denied или соответствующие ограничения. Для каталога с несколькими сайтами не открывайте общий родительский путь.
  5. Проверьте индексный файл и обработку PHPЕсли /index.php работает, но / вызывает 403 без индекса, найдите действующий DirectoryIndex (типично index.html index.php). Убедитесь, что реальный файл соответствует одному из имен. При необходимости добавьте DirectoryIndex index.php index.html в разрешённый контекст VirtualHost/Directory; не включайте Options +Indexes, чтобы показывать содержимое каталогов посетителям.
  6. Проверьте права прохода по всей цепочкеВыполните namei -l /фактический/public/index.php, предварительно подставив существующий файл. Для каждой папки по пути серверному пользователю нужно право поиска (x), а для чтения файла — соответствующее r. Системные пользователи различаются (www-data, apache). Не меняйте рекурсивно владельца всего сайта и не используйте chmod -R 777; на управляемом хостинге используйте настройки прав панели.
  7. Учитывайте SELinux и другие системы защитыЕсли обычные права верны, а журнал показывает отказ, проверьте контекст защиты: на системе с SELinux администратор может выполнить getenforce и прочитать журнал аудита, а для AppArmor — проверить статус профилей. Не отключайте механизмы защиты для проверки. Восстановление меток и правил делайте только по принятой в вашей ОС политике.
  8. Примените одну исправленную настройку и проверьтеСоздайте резервную копию файла VirtualHost, выполните sudo apache2ctl configtest, затем при Syntax OK — sudo systemctl reload apache2. Повторите запрос к главной, /index.php и закрытому служебному файлу (он должен остаться недоступным). Если появилась 500/403 в других местах, верните копию файла и повторите configtest и reload.
  9. Команды для отдельных ситуацийВыберите только подходящий вариант. Это не одна последовательность: часть команд диагностирует проблему, а часть меняет настройки или данные.
    Выберите подходящий вариант — это не команды для последовательного выполнения
    Вариант 1Запускаются в SSH; имя пути нужно заменить на существующий файл.
    Linux · Терминал (Bash)КомандаНужен sudo
    Запускаются в SSH; имя пути нужно заменить на существующий файл. Журнал содержит IP/URL, не публикуйте без обезличивания.
    sudo apache2ctl -S
    sudo tail -n 80 /var/log/apache2/error.log
    namei -l /var/www/example/public/index.php
    Вариант 2Иллюстрация только для проверенного публичного DocumentRoot, а не готовое разрешение для всей файловой сист…
    Текст
    Иллюстрация только для проверенного публичного DocumentRoot, а не готовое разрешение для всей файловой системы.
    <Directory "/var/www/example/public">
        Require all granted
        Options -Indexes
        DirectoryIndex index.php index.html
    </Directory>

#Как проверить результат

Главная и известный публичный файл отвечают корректно, нет новых отказов в error.log. При этом секретные файлы, закрытые подпапки и списки содержимого директорий по-прежнему недоступны.

#Если проблема не устранена

Если причина 403 осталась неясной, соберите путь DocumentRoot, вывод namei -l без секретов, виртуальный хост и запись error.log; проверяйте их вместе. Не пробуйте универсальные chmod/chown: это может сломать соседние сайты.

Так эту ошибку тоже называют

Источники и обновления

Последнее обновление статьи: 2 ноября 2026. Версии программ и интерфейсы меняются — если шаги не совпадают с вашей версией, сверяйтесь с документацией производителя.