Как установить и настроить Apache с mod_php на VPS

MAATRIX

Многие PHP-проекты и старые CMS рассчитаны именно на Apache с его .htaccess и модульной обработкой PHP. Установить Apache с mod_php на VPS — самый прямой путь запустить такой сайт: PHP работает внутри процесса веб-сервера, а правила переопределяются прямо в папках без правки основного конфига. Разберём установку по шагам и честно обсудим, когда mod_php стоит заменить на PHP-FPM.

Что такое mod_php и когда он уместен

mod_php — это модуль, встраивающий интерпретатор PHP прямо в процесс Apache. Когда приходит запрос к PHP-скрипту, его обрабатывает сам веб-сервер, без обращения к внешнему процессу. Исторически это самый простой способ запустить PHP: поставил модуль — и всё работает, никакой отдельной службы настраивать не нужно.

Главное удобство Apache — файлы .htaccess. Они позволяют переопределять правила веб-сервера прямо в каталоге сайта: редиректы, правила доступа, красивые URL. Множество готовых CMS и скриптов поставляются с готовым .htaccess, и на Apache они заводятся без переписывания конфигов. Для наследуемых проектов и хостинга, где важна совместимость, это решающий аргумент.

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

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

Подготовка VPS и установка Apache

Для типового сайта на PHP достаточно VPS с 2 ядрами и 2–4 ГБ RAM; из-за прожорливости prefork памяти лучше заложить с запасом. Начните с обновления и установки Apache:

apt update && apt upgrade -y
apt install apache2 -y
systemctl enable --now apache2

Проверьте, что сервер поднялся и отвечает:

systemctl status apache2
curl -I http://127.0.0.1

Откройте нужные порты в фаерволе, оставив снаружи только веб и SSH:

ufw allow 22/tcp
ufw allow 80/tcp
ufw allow 443/tcp
ufw enable

Локацию сервера выбирайте по аудитории сайта: для российских посетителей ниже пинг с RU-площадки, для зарубежного проекта — US или UK. У MAATRIX доступны все три локации с оплатой из России картой, СБП или криптой, поэтому запустить сайт можно без иностранных платёжных средств.

Установка mod_php и проверка PHP

Теперь поставим сам PHP вместе с модулем для Apache. В свежих Ubuntu ставится актуальная версия, например PHP 8.3, и модуль подключается автоматически:

apt install php libapache2-mod-php php-mysql php-curl php-xml php-mbstring -y
systemctl restart apache2

Пакет libapache2-mod-php — это и есть mod_php: при его установке Apache автоматически подключает модуль и начинает обрабатывать PHP внутри своих процессов. Остальные пакеты — это расширения PHP под типовые задачи: php-mysql для работы с базой MySQL или MariaDB, php-curl для запросов к внешним API, php-xml и php-mbstring для разбора данных и корректной работы с многобайтовыми строками, включая кириллицу. Набор расширений подбирают под конкретную CMS: большинство популярных движков в документации перечисляют, что им нужно. Недостающее расширение — частая причина, по которой сайт устанавливается наполовину и выдаёт непонятную ошибку, поэтому проще поставить типовой набор сразу.

После перезапуска Apache уже умеет обрабатывать PHP. Проверим это тестовым файлом в корне сайта:

echo "<?php phpinfo();" > /var/www/html/info.php

Откройте http://IP/info.php в браузере — если видите таблицу phpinfo, PHP работает. В строке Server API там будет указано Apache 2.0 Handler, что подтверждает работу именно через mod_php. После проверки обязательно удалите этот файл, потому что phpinfo раскрывает конфигурацию сервера:

rm /var/www/html/info.php

Настройка виртуального хоста

Один сервер может обслуживать несколько сайтов через виртуальные хосты. Для каждого создаётся отдельный конфиг в /etc/apache2/sites-available/. Сначала подготовьте каталог сайта:

mkdir -p /var/www/example/public
chown -R www-data:www-data /var/www/example

Создайте конфиг /etc/apache2/sites-available/example.conf:

<VirtualHost *:80>
    ServerName example.com
    ServerAlias www.example.com
    DocumentRoot /var/www/example/public

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

    ErrorLog ${APACHE_LOG_DIR}/example-error.log
    CustomLog ${APACHE_LOG_DIR}/example-access.log combined
</VirtualHost>

Ключевая строка здесь — AllowOverride All: именно она разрешает файлам .htaccess в каталоге сайта переопределять правила. Без неё .htaccess игнорируется, и половина CMS работать не будет. Включите сайт и перезагрузите Apache:

a2ensite example.conf
a2dissite 000-default.conf
apache2ctl configtest
systemctl reload apache2

Модули, .htaccess и красивые URL

Многие CMS требуют модуль rewrite для человекочитаемых адресов. Включите его и перезапустите сервер:

a2enmod rewrite
systemctl restart apache2

После этого правила из .htaccess вроде перенаправления всех запросов на index.php начнут действовать. Это стандартный механизм для WordPress и подобных движков: файл в корне сайта описывает, как формируются ссылки, и Apache применяет его на лету. Удобство в том, что менять правила можно без доступа к основному конфигу и без перезапуска сервера — достаточно отредактировать .htaccess в папке.

У этой гибкости есть цена: обработка .htaccess на каждый запрос немного замедляет сервер, потому что Apache проверяет эти файлы в каждой папке пути. На нагруженных сайтах правила выносят в основной конфиг и отключают .htaccess, задав AllowOverride None. Но для большинства проектов удобство важнее этой микрооптимизации, и .htaccess оставляют включённым.

HTTPS и когда переходить на PHP-FPM

Сайт без шифрования сегодня неполноценен. Проще всего выпустить бесплатный сертификат Let's Encrypt через certbot, который сам настроит виртуальный хост на 443:

apt install certbot python3-certbot-apache -y
certbot --apache -d example.com -d www.example.com

Certbot добавит SSL-хост, пропишет пути к сертификатам и настроит редирект с 80 на 443, а автопродление уже включено таймером. На этом типовой сайт на Apache с mod_php полностью готов.

Теперь о честном пределе mod_php. Если сайт растёт и памяти начинает не хватать, а под нагрузкой Apache плодит тяжёлые процессы, стоит перейти на связку с PHP-FPM. Тогда PHP обслуживается отдельным пулом процессов, а Apache работает в экономном событийном режиме. Переключение выглядит так:

apt install php-fpm libapache2-mod-fcgid -y
a2dismod php8.3
a2enconf php8.3-fpm
a2enmod proxy_fcgi
systemctl restart apache2

После этого Apache отдаёт статику и раздаёт PHP через FPM, потребляя заметно меньше памяти под нагрузкой. Это тот случай, когда рост проекта — повод либо сменить схему обработки PHP, либо взять VPS помощнее с запасом RAM и быстрым диском, чтобы держать больше посетителей без деградации.

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