Apache с mod_php на сервере: частые ошибки и решения

MAATRIX

Apache с mod_php ставится за минуту, а потом сайт то отдаёт PHP-код текстом, то падает с 500 из-за строки в .htaccess, то съедает всю память и виснет. Эти ошибки Apache с mod_php на сервере типовые, и у каждой понятная причина. Разберём их по схеме «симптом — причина — решение», чтобы вы чинили быстро и по делу, а не перебором.

Где искать причину: логи Apache

Первое правило — не гадать, а читать логи. У Apache два основных журнала, и они отвечают на разные вопросы. Общий лог ошибок показывает сбои старта и модулей, а лог конкретного сайта — ошибки его обработки:

tail -f /var/log/apache2/error.log
tail -f /var/log/apache2/example-error.log

Второе правило — проверять конфиг перед каждым перезапуском. Опечатка в виртуальном хосте роняет весь Apache, поэтому сначала тест, потом применение:

apache2ctl configtest
systemctl reload apache2

Команда configtest вернёт Syntax OK или укажет файл и строку с ошибкой. Это экономит нервы: вы не уроните рабочий сервер кривым конфигом. Держа лог ошибок открытым во время воспроизведения проблемы, вы почти всегда увидите точную причину — от отсутствующего модуля до запрета доступа к каталогу. Дальше разберём частые симптомы по отдельности.

PHP-код отдаётся как текст

Пугающий симптом: вместо страницы браузер показывает исходный код PHP или предлагает скачать файл .php. Это значит, что Apache не обрабатывает PHP, а отдаёт его как обычный файл. Причина — не установлен или не включён модуль PHP.

Проверьте, стоит ли mod_php и активен ли он:

apachectl -M | grep php
apt install libapache2-mod-php -y
systemctl restart apache2

Если в списке модулей нет строки с php, модуль не подключён. После установки libapache2-mod-php и перезапуска Apache начнёт обрабатывать PHP. Отдельный случай — если вы переходили на PHP-FPM и отключили mod_php, но не настроили FPM: тогда PHP тоже отдаётся текстом, потому что обрабатывать его некому. В этой ситуации нужно либо вернуть mod_php, либо корректно включить обработку через FPM с модулем proxy_fcgi. Проверить, какой обработчик активен, помогает файл с phpinfo() — но не забудьте удалить его сразу после проверки.

Ошибка 500 из-за .htaccess

Классика: сайт работал, вы добавили строку в .htaccess — и весь сайт отдаёт 500 Internal Server Error. Причина в том, что .htaccess применяется на каждый запрос, и любая неподдерживаемая директива в нём валит обработку. Чаще всего это правило, требующее модуль, который не включён.

Первым делом посмотрите, что именно ругается, в логе ошибок сайта:

tail -n 20 /var/log/apache2/example-error.log

Частая причина — правила RewriteRule без включённого модуля rewrite. Лечится включением модуля:

a2enmod rewrite
systemctl restart apache2

Если в логе .htaccess: Invalid command — значит, директива относится к невключённому модулю, и нужно либо поставить его, либо убрать строку. Ещё одна тонкость: чтобы .htaccess вообще действовал, в виртуальном хосте должно стоять AllowOverride All для каталога сайта. Обратная ошибка — когда .htaccess игнорируется полностью, тоже упирается в этот параметр, только со значением None. Проверяйте согласованность: либо .htaccess разрешён и корректен, либо отключён и правила вынесены в конфиг.

Ошибка 403 Forbidden

Сайт настроен, но открывается 403 Forbidden — доступ запрещён. Причин у этой ошибки несколько, и все проверяются быстро. Первая — права доступа к файлам сайта: Apache работает под пользователем www-data, и если файлы принадлежат другому пользователю без прав на чтение, доступа не будет.

chown -R www-data:www-data /var/www/example
find /var/www/example -type d -exec chmod 755 {} \;
find /var/www/example -type f -exec chmod 644 {} \;

Вторая причина — отсутствие индексного файла. Если в каталоге нет index.php или index.html, а листинг каталога запрещён, Apache отдаёт 403. Третья — директива Require all granted не задана для каталога, и доступ по умолчанию закрыт. Проверьте, что в блоке <Directory> вашего виртуального хоста есть разрешение:

<Directory /var/www/example/public>
    Require all granted
</Directory>

Четвёртая, более тонкая причина — SELinux на системах, где он включён, блокирует доступ Apache к нестандартному пути. На Ubuntu по умолчанию его нет, но на некоторых образах он присутствует и требует отдельной настройки контекста файлов.

Нехватка памяти и зависания под нагрузкой

Опасный симптом: под наплывом посетителей сайт замедляется, потом перестаёт отвечать, а сервер уходит в своп. Это врождённая особенность mod_php с рабочим модулем prefork: каждый процесс Apache несёт полный интерпретатор PHP и занимает десятки мегабайт, поэтому сотня одновременных соединений легко съедает всю RAM.

Посмотрите потребление памяти и число процессов Apache:

free -m
ps -ylC apache2 --sort:rss | awk '{sum+=$8} END {print sum/1024 " MB"}'

Первое, что стоит сделать, — ограничить максимальное число рабочих процессов в настройках prefork, исходя из объёма памяти. Если каждый процесс занимает около 40 МБ, а под Apache отведён гигабайт, разумный предел — порядка двадцати процессов, иначе сервер уйдёт в своп и встанет полностью. Параметр MaxRequestWorkers задаётся в конфиге модуля mpm_prefork.

Но правильное решение при постоянной нехватке памяти — сменить схему на PHP-FPM с событийным модулем Apache. Тогда статику отдаёт лёгкий процесс, а PHP обслуживает отдельный экономный пул. Это радикально снижает потребление памяти под нагрузкой. Если же и после перехода на FPM ресурсов не хватает, значит, проекту объективно нужен более мощный сервер — с большим объёмом RAM и быстрым NVMe. У MAATRIX такие VPS доступны в локациях RU, US и UK с оплатой из России картой или криптой, и апгрейд решает то, что не решить тонкой настройкой на маломощной машине.

Профилактика типовых ошибок

Большинство описанных проблем не повторяются при аккуратной первичной настройке. Держите включёнными нужные модули (rewrite для CMS), задавайте корректный AllowOverride осознанно, выставляйте владельца файлов www-data и права 755/644, а в каждом виртуальном хосте прописывайте Require all granted для каталога сайта. Тестируйте конфиг через configtest перед каждым перезапуском и держите лог ошибок под рукой.

Отдельно следите за памятью. Для mod_php это главный ресурс риска: ограничьте число процессов под реальный объём RAM и подключите мониторинг, чтобы ловить приближение к потолку заранее, а не по факту зависания. Если сайт стабильно упирается в память, не тяните с переходом на PHP-FPM или с апгрейдом сервера — на нагруженном проекте это не роскошь, а условие стабильной работы. Правильно подобранное железо снимает целый класс «ошибок Apache», которые на деле были нехваткой ресурсов.

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