Безопасное выполнение PHP: экспертная настройка PHP-FPM с NGINX

watch 2m, 7s
views 2

10:19, 19.08.2026

Содержание статьи
arrow

  • Как работает PHP-FPM «за кулисами»
  • Требования перед настройкой PHP-FPM с NGINX
  • Пошаговое руководство по настройке PHP-FPM с NGINX
  • Шаг 1: Установка PHP-FPM на сервере
  • Шаг 2: Настройка пула PHP-FPM
  • Шаг 3: Настройка NGINX на использование PHP-FPM
  • Шаг 4: Проверка интеграции PHP-FPM и NGINX
  • Часто задаваемые вопросы и устранение неполадок
  • Что такое PHP-FPM и зачем использовать его вместе с NGINX?
  • Как правильно настроить связь между NGINX и PHP-FPM?
  • Когда следует использовать сокет, а когда порт в PHP-FPM?
  • Что вызывает ошибку 502 Bad Gateway и как её исправить?
  • Можно ли запускать несколько версий PHP в одной конфигурации NGINX?
  • Где можно найти настройки пула PHP-FPM?
  • Каковы лучшие практики для повышения производительности PHP-FPM?
  • Заключительные замечания

PHP-FPM — это диспетчер процессов, необходимый для обработки веб-запросов. Этот подход значительно быстрее по сравнению с традиционными методами CGI, такими как mod_php или SUPHP. Главное преимущество этого метода заключается в том, что он требует меньших ресурсов процессора и памяти.  

Как работает PHP-FPM «за кулисами»

Чтобы лучше понять, как всё работает, давайте рассмотрим, что происходит «за кулисами». Вот основные этапы работы системы:

  1. Обработка запроса. Когда сервер получает запрос от PHP-скрипта, он передаётся через FastCGI в PHP-FPM.
  2. Управление процессами. После получения запроса PHP-FPM выбирает из пула доступный процесс для его обработки. Если доступных процессов нет, создаётся новый.
  3. Можно управлять различными типами процессов, такими как главный и рабочие процессы. Главный процесс необходим для прослушивания поступающих запросов и их распределения между доступными рабочими процессами. Рабочий процесс необходим для выполнения скриптов PHP. Они могут работать в различных режимах, таких как статический, динамический и «по запросу».
  4. Выполнение. Когда запрос поступает в рабочий процесс, выполняется скрипт PHP, и на сервер выводится результат.
  5. Рециркуляция процесса. Рабочие процессы могут перезапускаться после определенного количества запросов. Это необходимо для предотвращения утечек памяти

Требования перед настройкой PHP-FPM с NGINX

-        SSH-сессию в вашей системе можно открыть с правами пользователя sudo или root.

-        Установка PHP и NGINX в вашей системе. Если они ещё не установлены, существуют различные подробные инструкции по процессу установки.

Пошаговое руководство по настройке PHP-FPM с NGINX

-        Установка PHP-FPM

-        Настройка пула PHP-FPM

-        Настройка NGINX на использование PHP-FPM

-        Проверка интеграции PHP-FPM и NGINX

Шаг 1: Установка PHP-FPM на сервере

Скрипт PHP не может запускаться в Nginx, поскольку для эффективного управления необходим PHP-FPM. PHP-FPM работает вне NGINX, создавая собственный процесс. Когда пользователь пытается перейти на страницу PHP, сервер передаёт этот запрос в PHP-FPM.

Процесс установки в Ubuntu зависит от версии системы и PHP. После того как вы убедитесь, что у вас установлена последняя версия PHP, вы можете использовать следующую команду для установки FPM:

sudo apt install -y php8.2-fpm

После выполнения приведённой выше команды сервер запустится автоматически по завершении установки. Для проверки используйте следующую команду:

sudo systemctl status php8.2-fpm

Шаг 2: Настройка пула PHP-FPM

Пул по умолчанию находится в папке /etc/php/8.2/fpm/pool.d/, которую можно настроить в соответствии с вашими требованиями. Однако более распространённым подходом является создание отдельных пулов для лучшего контроля над каждым процессом FPM. Каждый пул будет иметь свой главный процесс, и каждое PHP-приложение можно настроить с собственным кэшем. Это довольно удобный подход, поскольку пулы будут раздельными, и любые изменения в одном пуле не повлияют на остальные.

Теперь давайте создадим пул FPM для запуска приложения под отдельным пользователем. Для начала создадим нового пользователя:

# Создадим системную группу с именем wordpress

sudo groupadd --system wordpress

# Создайте системного пользователя с именем wordpress, добавьте его в группу wordpress и установите, чтобы у него не было оболочки входа в систему

sudo useradd --system --gid wordpress --shell /usr/sbin/nologin --home-dir /var/www/wordpress wordpress

Следующим шагом будет переход в каталог конфигурации и создание файла конфигурации с помощью текстового редактора:

# cd /etc/php/8.2/fpm/pool.d

# vi wordpress_pool.conf

[wordpress_site]

user = wordpress

group = wordpress

listen = /run/php/php8.2-fpm-wordpress.sock

listen.owner = www-data

listen.group = www-data

 

php_admin_value[disable_functions] = exec,passthru,shell_exec,system

php_admin_flag[allow_url_fopen] = off

 

pm = dynamic

pm.max_children = 75

pm.start_servers = 10

pm.min_spare_servers = 5

pm.max_spare_servers = 20

pm.process_idle_timeout = 10s

Давайте рассмотрим некоторые из вышеупомянутых значений:

-        [wordpress_site]: здесь должно быть указано уникальное имя пула.

-        Пользователь/группа: укажите, под каким именем будет запущен пул.

-        Listen: имя файла сокета.

-        Listen.owner/group: должно совпадать с именем пользователя/группы NGINX.

-        Admin_value/flag: позволяет задавать пользовательские значения и булевы флаги.

-        pm: при выборе значения «Dynamic» количество дочерних процессов определяется на основе последующих директив.

-        max_children: максимальное количество дочерних процессов, которые могут быть активны одновременно.

-        start_servers: количество дочерних процессов, создаваемых при запуске.

-         max/min_spare_servers: максимальное и минимальное количество дочерних процессов, находящихся в состоянии простоя.

-        idle_timeout: максимальное количество простаивающих серверных процессов.

Кроме того, можно выбрать настройки «static» (статические) и «on-demand» (по требованию). При выборе варианта «static» количество процессов будет фиксированным, а при выборе «on-demand» дочерние процессы будут запускаться для новых запросов.

После завершения работы с файлом конфигурации перезапустите службу fpm:

sudo systemctl restart php8.2-fpm

Шаг 3: Настройка NGINX на использование PHP-FPM

Следующим шагом является создание блока сервера NGINX. Для этого необходимо отредактировать конфигурационный файл NGINX и добавить путь к файлу сокета пула с помощью fastcgi_pass следующим образом:

location ~ \.php$ {

    fastcgi_split_path_info ^(.+\.php)(/.+)$;

    fastcgi_pass unix:/run/php/php8.2-fpm-wordpress.sock;

    fastcgi_index index.php;

    include fastcgi.conf;

}

После этого перезапустите NGINX:

sudo nginx -t

sudo systemctl reload nginx

Шаг 4: Проверка интеграции PHP-FPM и NGINX

Чтобы проверить, действительно ли конфигурационный файл использует новый пул, необходимо создать файл php.info в корневом каталоге.

# Перейдите в каталог WordPress

cd /var/www/html/wordpress

# Создайте файл PHP info с использованием безопасных кавычек

echo '<?php phpinfo(); ?>' | sudo tee info.php > /dev/null

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

Часто задаваемые вопросы и устранение неполадок

Что такое PHP-FPM и зачем использовать его вместе с NGINX?

PHP-FPM — это диспетчер процессов, необходимый для управления процессами PHP. В сочетании с NGINX он позволяет значительно повысить безопасность, производительность и эффективность управления ресурсами.

Как правильно настроить связь между NGINX и PHP-FPM?

Для установки связи необходимо настроить NGINX на использование PHP-FPM. Это можно сделать, включив директиву fastcgi_pass в файл конфигурации. Это можно сделать следующим образом:

location ~ \.php$ {

fastcgi_split_path_info ^(.+\.php)(/.+)$;

fastcgi_pass unix:/run/php/php8.2-fpm-wordpress.sock;

fastcgi_index index.php;

include fastcgi.conf;

}

Когда следует использовать сокет, а когда порт в PHP-FPM?

Использование сокетов обеспечивает более быструю связь, поскольку исключается сетевая нагрузка. Порт требует сетевого взаимодействия, и такой подход значительно медленнее. Тем не менее, использование порта может быть целесообразно в тех случаях, когда FPM работает на разных контейнерах или серверах.

Что вызывает ошибку 502 Bad Gateway и как её исправить?

Чтобы устранить эту ошибку, необходимо проверить, работает ли FPM и правильно ли указан протокол TCP или сокет в конфигурации NGINX. Просмотрите журналы FPM на наличие проблем и соответствующим образом измените настройки пула. Кроме того, проверьте, правильно ли конфигурация NGINX пропускает запросы PHP.

Для проверки журналов используйте следующую команду:

tail -f /var/log/php8.2-fpm.log

Можно ли запускать несколько версий PHP в одной конфигурации NGINX?

Конечно, это можно сделать, настроив отдельные пулы и указав нужный пул для каждого домена/поддомена. Например, если вы используете PHP 7.4 и 7.2, это возможно. После этого укажите нужный пул для каждого домена. 

Где можно найти настройки пула PHP-FPM?

Обычно пул находится в /etc/php/8.2/fpm/pool.d/.

Каковы лучшие практики для повышения производительности PHP-FPM?

Для повышения производительности может потребоваться настроить параметры pm.min_spare_servers, pm.max_children и pm.start_servers в конфигурации. Кроме того, можно попробовать включить параметры pm.status_path и pm.max_requests.

Заключительные замечания

В этой статье мы на практике показали, как настроить отдельные пулы, установить PHP-FPM, настроить блок сервера NGINX и подключиться к службе. Используя этот подход, можно обеспечить лучшую масштабируемость, безопасность и улучшить показатели производительности. Теперь вы знаете, как наиболее оптимально распределять ресурсы сервера.

Поделиться

Была ли эта статья полезной для вас?

Популярные предложения VPS

-15.6%

CPU
CPU
2 Xeon Cores
RAM
RAM
512 MB
Space
Space
10 GB SSD
Bandwidth
Bandwidth
1 TB
KVM-SSD 512 Metered Linux

5.33

При оплате за год

-21.4%

CPU
CPU
6 Xeon Cores
RAM
RAM
8 GB
Space
Space
100 GB SSD
Bandwidth
Bandwidth
500 GB
wKVM-SSD 8192 HK Windows

67

При оплате за год

-4.5%

CPU
CPU
4 Xeon Cores
RAM
RAM
4 GB
Space
Space
100 GB HDD
Bandwidth
Bandwidth
300 Gb
wKVM-HDD HK 4096 Windows

17.09

При оплате за год

-9.3%

CPU
CPU
6 Epyc Cores
RAM
RAM
16 GB
Space
Space
150 GB NVMe
Bandwidth
Bandwidth
Unlimited
wKVM-NVMe 16384 Windows

54.49

При оплате за год

-10%

CPU
CPU
4 Xeon Cores
RAM
RAM
2 GB
Space
Space
60 GB HDD
Bandwidth
Bandwidth
300 Gb
KVM-HDD HK 2048 Linux

6.3

При оплате за год

-8.9%

CPU
CPU
6 Xeon Cores
RAM
RAM
16 GB
Space
Space
400 GB HDD
Bandwidth
Bandwidth
Unlimited
wKVM-HDD 16384 Windows

56

При оплате за год

-8.1%

CPU
CPU
6 Xeon Cores
RAM
RAM
8 GB
Space
Space
200 GB HDD
Bandwidth
Bandwidth
Unlimited
wKVM-HDD 8192 Windows

31.25

При оплате за год

-10%

CPU
CPU
6 Xeon Cores
RAM
RAM
8 GB
Space
Space
100 GB SSD
Bandwidth
Bandwidth
Unlimited
wKVM-SSD 8192 Windows

28.44

При оплате за год

-18.4%

CPU
CPU
4 Xeon Cores
RAM
RAM
2 GB
Space
Space
75 GB SSD
Bandwidth
Bandwidth
2 TB
wKVM-SSD 2048 Metered Windows

24

При оплате за год

-7.1%

CPU
CPU
4 Xeon Cores
RAM
RAM
4 GB
Space
Space
100 GB HDD
Bandwidth
Bandwidth
Unlimited
wKVM-HDD 4096 Windows

21

При оплате за год

Другие статьи на эту тему

cookie

Принять файлы cookie и политику конфиденциальности?

Мы используем файлы cookie, чтобы обеспечить вам наилучший опыт работы на нашем сайте. Если вы продолжите работу без изменения настроек, мы будем считать, что вы согласны получать все файлы cookie на сайте HostZealot.