Как установить PHP-FPM для WordPress и проверить его работу

PHP-FPM принимает от Nginx запрос к PHP-файлу и выполняет WordPress в одном из рабочих процессов. До установки выберите поддерживаемый выпуск ОС и не смешивайте пакеты из нескольких сторонних репозиториев: так проще получать обновления и восстанавливать конфигурацию.

Названия службы и каталогов содержат версию PHP. В командах ниже сначала определяется фактически установленная версия; не подставляйте число из чужой инструкции.

Установите PHP и базовые расширения

Обновите индекс пакетов и установите FPM вместе с расширениями, которые нужны обычной установке WordPress. Пакет php-mysql добавляет драйвер для MariaDB/MySQL, остальные отвечают за HTTP-запросы, изображения, многобайтовые строки, XML, архивы и локализацию:

sudo apt update
sudo apt install php-fpm php-mysql php-curl php-gd php-mbstring php-xml php-zip php-intl

Перед подтверждением apt покажет список пакетов и объём. Если система предлагает удалить важные компоненты или заменить пакеты из неизвестного репозитория, отмените операцию и проверьте источники. После установки узнайте версию CLI и имя FPM-службы:

php --version
systemctl list-unit-files --type=service | grep 'php.*-fpm.service'
php --ini

Версия командной строки и FPM обычно совпадает, но это нужно проверить. php --ini показывает конфигурацию CLI; веб-запросы используют отдельный каталог fpm, поэтому изменение CLI-файла не обязательно влияет на сайт.

Найдите пул и его сокет

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

systemctl --type=service --all | grep 'php.*-fpm'
sudo grep -R -E '^[[:space:]]*(user|group|listen|pm|max_children)' /etc/php/*/fpm/pool.d/
sudo ss -lxnp | grep php

В стандартной конфигурации процесс работает как www-data, а listen указывает на файл внутри /run/php/. Путь из фактического файла пула понадобится в fastcgi_pass. Если ss не показывает сокет, проверьте состояние найденной службы и её журнал.

Задайте лимиты по измерениям

Режим dynamic держит несколько готовых работников и меняет их число до pm.max_children. Режим ondemand создаёт процессы по запросу и может экономить память на редко посещаемом сайте ценой запуска работника. static всегда держит фиксированное число процессов.

Начните со штатных значений пакета и наблюдайте. Под нагрузкой посмотрите число процессов и их резидентную память. В следующей команде rss показан в килобайтах:

ps -C php-fpm -o pid,rss,etime,cmd --sort=-rss
free -h
journalctl -k -b --no-pager | grep -i -E 'out of memory|killed process'

Один главный процесс и несколько работников — нормальная картина. Оценивайте верхнюю границу памяти работников, оставляя запас MariaDB, Nginx, ОС и файловому кешу. Сообщения OOM означают, что лимиты уже опасны; увеличение pm.max_children ухудшит ситуацию.

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

[example]
user = www-data
group = www-data
listen = /run/php/php-example.sock
listen.owner = www-data
listen.group = www-data
listen.mode = 0660
pm = dynamic
pm.max_children = 6
pm.start_servers = 2
pm.min_spare_servers = 1
pm.max_spare_servers = 3
php_admin_flag[display_errors] = off
php_admin_flag[log_errors] = on

Имя пула example, путь сокета и предел 6 нужно адаптировать. Параметры spare применяются к dynamic: они определяют число свободных работников. Перед заменой рабочего пула сохраните его файл и убедитесь, что Nginx будет указывать на новый сокет.

Проверьте конфигурацию до перезапуска

Исполняемый файл FPM также содержит версию. Найдите его и запустите тест конфигурации; затем примените изменения reload и прочитайте состояние службы:

command -v php-fpm || find /usr/sbin -maxdepth 1 -name 'php-fpm*' -type f
sudo /usr/sbin/php-fpm8.3 -t
sudo systemctl reload php8.3-fpm
systemctl status php8.3-fpm --no-pager

В двух последних командах 8.3 — пример: замените его версией из имени обнаруженного файла и службы. Тест должен завершиться сообщением об успешной конфигурации. При ошибке не выполняйте reload; верните изменённый файл или исправьте указанную строку.

Подключите Nginx к сокету

Внутри обработчика PHP параметр fastcgi_pass должен указывать на существующий сокет. SCRIPT_FILENAME передаёт PHP полный путь к сценарию:

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

Не добавляйте такой обработчик без правила маршрутизации WordPress и запрета выполнения PHP в каталоге загрузок; полноценный виртуальный хост разбирается отдельно. После правки выполните sudo nginx -t, затем reload и запросите тестовую страницу.

Не оставляйте файл с phpinfo() на рабочем сайте: он раскрывает версии, пути и переменные среды. Для проверки достаточно временного файла с простым ответом, доступного только с вашего IP, и его немедленного удаления после успешного запроса.

Диагностируйте 502 по обе стороны сокета

Если Nginx возвращает 502, сначала сопоставьте путь сокета, владельца и состояние службы. Затем прочитайте оба журнала за один временной интервал:

sudo namei -l /run/php/php-example.sock
journalctl -u php8.3-fpm -b --since '-10 minutes' --no-pager
sudo tail -n 100 /var/log/nginx/error.log

Версию службы снова замените на установленную. namei -l показывает права каждого элемента пути. Ошибка Permission denied требует исправить владельца сокета или группу Nginx, а No such file — проверить имя пула и запущена ли служба.

После установки переходите к локальной базе MariaDB и только затем к файлам WordPress. Так каждый слой проверяется до появления следующего.

Источники

• PHP manual: FastCGI Process Manager
• PHP manual: FPM configuration
• WordPress: server requirements
• Nginx: FastCGI module