# Plesk: разбиране на PHP handler-ите (FPM, FastCGI, Apache модул)

> Сравнение на Plesk PHP handler-ите: FPM, Dedicated FPM, FastCGI и Apache модул от гледна точка на сигурността, с бележки за PHP2Shell, nginx и .htaccess.

Източник: https://phpsos.de/bg/blog/plesk-php-handler/  
Актуалност: 25.10.2026  
Доставчик: PHP SOS, Спешна помощ за PHP и сигурност на сървъри. Незабавна помощ по WhatsApp: https://wa.me/491736494914?text=%D0%97%D0%B4%D1%80%D0%B0%D0%B2%D0%B5%D0%B9%D1%82%D0%B5%2C%20PHP%20SOS%2C%20%D0%B8%D0%BC%D0%B0%D0%BC%D0%B5%20%D0%BD%D1%83%D0%B6%D0%B4%D0%B0%20%D0%BE%D1%82%20%D0%BF%D0%BE%D0%BC%D0%BE%D1%89%20%D1%81%20%D0%BD%D0%B0%D1%88%D0%B8%D1%8F%20PHP%20%D1%81%D1%8A%D1%80%D0%B2%D1%8A%D1%80.%20%D0%A4%D0%B8%D1%80%D0%BC%D0%B0%3A%20%E2%80%A6%20%D0%A3%D0%B5%D0%B1%D1%81%D0%B0%D0%B9%D1%82%3A%20%E2%80%A6

**Накратко:** PHP handler-ът в Plesk определя как работи PHP за даден уебсайт: като FPM приложение със споделен пул, като Dedicated FPM със собствен пул за всеки уебсайт, като FastCGI приложение или като Apache модул (mod_php). От гледна точка на сигурността Dedicated FPM е при Linux обикновено най-добрият избор, а Apache модулът - най-лошият. Самият Plesk го определя като остарял, респективно несигурен, а при PHP2Shell екипът на PHP вижда най-високия риск точно при mod_php.

## Защо handler-ът е повече от въпрос на производителност

В Plesk за всеки уебсайт избирате версия на PHP и handler. Мнозина третират handler-а като подробност за производителността и паметта. Той обаче решава и колко силно са разделени уебсайтовете един от друг, къде действат настройките за сигурност и кои процеси трябва да бъдат рестартирани след актуализация.

След PHP2Shell този избор става конкретен. Уязвимостите CVE-2026-109618 и CVE-2026-109619 засягат всички разпространени режими на работа, но екипът на PHP оценява риска при mod_php като най-висок. Който на своя Plesk сървър още поддържа домейни с Apache модула, трябва да промени това сега. Как да проверите версиите и да ги пачнете, описва страницата [Plesk сървър: проверка и пачване на версиите на PHP](https://phpsos.de/bg/server/plesk/); тук става дума за избора на режим на работа.

## PHP handler-ите на Plesk накратко

Следният преглед се основава на документацията на Plesk за Plesk Obsidian, допълнена с гледната точка на сигурността. При Linux FPM handler-ите според Plesk могат по избор да се обслужват през Apache или nginx, а FastCGI винаги през Apache.

| Handler | Обслужва се през | Изолация | Препоръка според Plesk | Гледна точка на сигурността |
|---|---|---|---|---|
| Dedicated FPM application | Apache или nginx | собствен пул за всеки уебсайт | Linux със споделен хостинг | най-добро разделяне, собствени стойности за всеки пул |
| FPM application | Apache или nginx | споделен пул за всяка версия на PHP | dedicated Linux сървъри | неизправен уебсайт може да смути други със същата версия |
| FastCGI application | Apache (Linux) | постоянни процеси, добро разделяне | Windows сървъри | стабилен, при Linux обикновено заменен от FPM |
| Apache module (mod_php) | Apache | PHP в процеса на уеб сървъра | не се препоръчва | най-висок риск от PHP2Shell според екипа на PHP |
| CGI application | Apache | нов процес за всяка заявка | не се препоръчва | остарял |

Контекста за самите режими на работа обясняват страниците [PHP-FPM обяснен](https://phpsos.de/bg/php/php-fpm-erklaert/) и [Защо mod_php носи най-висок риск](https://phpsos.de/bg/php2shell/mod-php-risiko/).

## Споделен или собствен пул?

Разликата между FPM и Dedicated FPM често се подценява. При обикновения FPM handler според Plesk всички уебсайтове със същата версия на PHP споделят един пул от процеси. Това спестява памет, но означава също: уебсайт, който създава проблеми, може да повлече всички останали със същата версия, а общият кеш се споделя.

Dedicated FPM дава на всеки уебсайт собствен пул. Според Plesk това подобрява изолацията и производителността, но струва повече памет. От гледна точка на сигурността собственият пул е основата за поставянето на настройки като `open_basedir`, ограничения на паметта или лимити за качване отделно за всеки уебсайт. Как да разделите пуловете последователно, описва статията [Изолиране на PHP-FPM пуловете за всеки уебсайт](https://phpsos.de/bg/blog/php-fpm-pools-isolieren/).

## nginx или Apache: капанът .htaccess

Ако изберете handler, който се обслужва през nginx, се променя нещо основно: според Plesk тези handler-и пренебрегват файла `.htaccess`. Което стои там, вече не действа.

Това е тема за сигурността. Много приложения и администратори слагат защитни правила в `.htaccess`, например забрана за изпълнение на PHP файлове в директории за качване или блокиране на конфигурационни файлове. След преминаване към nginx тези правила мълчаливо губят сила. Затова преди смяната проверете кои защитни правила стоят в `.htaccess` и ги пренесете в конфигурацията на nginx за домейна.

> **Важно:**
> Смяната на handler е промяна в конфигурацията за сигурност. След нея тествайте целенасочено дали блокираните пътища остават блокирани, а не само дали се зарежда началната страница.

## Проверка и превключване на handler-а

Първо добийте преглед кои домейни ползват кой handler. Командите са само за четене.

```bash
# Всички регистрирани handler-и с ID, версия и тип
plesk bin php_handler --list

# Домейни, които ползват определен handler (ID от списъка)
plesk bin php_handler --get-usage -id <handler-id>

# PHP работи ли в процеса на Apache? (Debian/Ubuntu: apache2ctl, RHEL семейство: httpd)
apache2ctl -M 2>/dev/null | grep -i php
```

За превключването действайте домейн по домейн:

1. Запишете защитните правила от `.htaccess`, ако новият handler се обслужва през nginx.
2. Задайте преходните стойности срещу PHP2Shell, например `session.upload_progress.enabled=0`, за новия handler. При FPM те се поставят като `php_admin_value` в допълнителните директиви на пула, при FastCGI действат други пътища.
3. Сменете handler-а в PHP настройките на домейна, по възможност първо върху копие.
4. Тествайте функциите и проверете дали домейнът се обслужва от процеси с актуален код.
5. Ако Apache модулът вече не се ползва от нито един домейн, деактивирайте handler-а.

## В какъв ред да превключвате?

На изградил се с времето Plesk сървър рядко може да се превключи всичко за един ден. Редът според риска помага да се използва пестеливото време смислено:

- **Първо домейните с Apache модул**, защото там рискът от PHP2Shell според екипа на PHP е най-висок, а Plesk така или иначе не го препоръчва.
- **После домейните с чувствителни данни**, например магазини, клиентски портали или формуляри със здравни или договорни данни. Тук собственият пул си заслужава особено.
- **След това домейните на стари версии на PHP**, които така или иначе трябва да се превключат. Handler и версия могат да се сменят заедно в рамките на един прозорец за поддръжка.
- **Накрая смяната от споделен към собствен пул** за останалите домейни, ако паметта на сървъра го позволява.

Преди последното стъпало проверете натоварването на паметта. Plesk посочва, че Dedicated FPM изисква повече памет, и при много уебсайтове съветва наблюдение. Сървър, който след превключването почва да използва swap, става бавен, а оскъдната памет точно при PHP2Shell не е добро състояние.

## Как помага PHP SOS конкретно?

- Установяваме кои домейни на Вашия Plesk сървър ползват кой handler и маркираме домейните с Apache модул.
- Превключваме към Dedicated FPM и пренасяме защитните правила от `.htaccess` в конфигурацията на nginx, където е нужно.
- Задаваме преходни стойности и ограничения за всеки пул и проверяваме, че действат в уеб контекста.
- В рамките на [втвърдяването на сървъри](https://phpsos.de/bg/leistungen/server-haertung/) деактивираме остарелите handler-и и документираме конфигурацията.


## Често задавани въпроси

**Кой PHP handler препоръчва Plesk?**  
Според документацията на Plesk FPM е препоръчителният handler за dedicated Linux сървъри, Dedicated FPM - за Linux сървъри със споделен хостинг, а FastCGI - за Windows сървъри. Apache модулът, CGI и ISAPI Plesk определя като силно остарели, респективно несигурни.

**Защо handler-ът Apache модул е особено критичен след PHP2Shell?**  
Handler-ът съответства на mod_php. Екипът на PHP оценява риска от PHP2Shell при mod_php като най-висок, защото там е показан експлойт, преди да се изпълни кодът на приложението. Освен това самият Plesk не препоръчва този handler.

**Какво се променя, ако PHP се обслужва през nginx вместо Apache?**  
Според Plesk handler-ите, обслужвани през nginx, пренебрегват файла .htaccess. Правила за сигурност, които стоят там, например блокиране на PHP в директории за качване, вече не действат и трябва да се пренесат в правила на nginx.

**Трябва ли да рестартирам PHP след смяна на handler?**  
След смяната проверете кои PHP процеси работят за домейна и от кога. При Dedicated FPM домейнът получава собствен пул. Стар процес със остарял код след това не бива да работи за домейна.

**Dedicated FPM винаги ли е най-добрият избор?**  
За изолацията - да, защото всеки уебсайт получава собствен пул. Цената е по-голяма нужда от памет. Plesk съветва при сървъри с много уебсайтове това да се наблюдава.

## Източници

- [Документация на Plesk: Choosing the PHP Handler](https://docs.plesk.com/en-US/obsidian/administrator-guide/75145/)
- [Документация на Plesk: php_handler](https://docs.plesk.com/en-US/obsidian/cli-linux/using-command-line-utilities/php_handler-php-handlers.72490/)
- [php.net: Съобщения за сигурност](https://www.php.net/)