Накратко: 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; тук става дума за избора на режим на работа.
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 обяснен и Защо mod_php носи най-висок риск.
Споделен или собствен пул?
Разликата между FPM и Dedicated FPM често се подценява. При обикновения FPM handler според Plesk всички уебсайтове със същата версия на PHP споделят един пул от процеси. Това спестява памет, но означава също: уебсайт, който създава проблеми, може да повлече всички останали със същата версия, а общият кеш се споделя.
Dedicated FPM дава на всеки уебсайт собствен пул. Според Plesk това подобрява изолацията и производителността, но струва повече памет. От гледна точка на сигурността собственият пул е основата за поставянето на настройки като open_basedir, ограничения на паметта или лимити за качване отделно за всеки уебсайт. Как да разделите пуловете последователно, описва статията Изолиране на PHP-FPM пуловете за всеки уебсайт.
nginx или Apache: капанът .htaccess
Ако изберете handler, който се обслужва през nginx, се променя нещо основно: според Plesk тези handler-и пренебрегват файла .htaccess. Което стои там, вече не действа.
Това е тема за сигурността. Много приложения и администратори слагат защитни правила в .htaccess, например забрана за изпълнение на PHP файлове в директории за качване или блокиране на конфигурационни файлове. След преминаване към nginx тези правила мълчаливо губят сила. Затова преди смяната проверете кои защитни правила стоят в .htaccess и ги пренесете в конфигурацията на nginx за домейна.
Смяната на handler е промяна в конфигурацията за сигурност. След нея тествайте целенасочено дали блокираните пътища остават блокирани, а не само дали се зарежда началната страница.
Проверка и превключване на handler-а
Първо добийте преглед кои домейни ползват кой handler. Командите са само за четене.
# Всички регистрирани 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
За превключването действайте домейн по домейн:
- Запишете защитните правила от
.htaccess, ако новият handler се обслужва през nginx. - Задайте преходните стойности срещу PHP2Shell, например
session.upload_progress.enabled=0, за новия handler. При FPM те се поставят катоphp_admin_valueв допълнителните директиви на пула, при FastCGI действат други пътища. - Сменете handler-а в PHP настройките на домейна, по възможност първо върху копие.
- Тествайте функциите и проверете дали домейнът се обслужва от процеси с актуален код.
- Ако Apache модулът вече не се ползва от нито един домейн, деактивирайте handler-а.
В какъв ред да превключвате?
На изградил се с времето Plesk сървър рядко може да се превключи всичко за един ден. Редът според риска помага да се използва пестеливото време смислено:
- Първо домейните с Apache модул, защото там рискът от PHP2Shell според екипа на PHP е най-висок, а Plesk така или иначе не го препоръчва.
- После домейните с чувствителни данни, например магазини, клиентски портали или формуляри със здравни или договорни данни. Тук собственият пул си заслужава особено.
- След това домейните на стари версии на PHP, които така или иначе трябва да се превключат. Handler и версия могат да се сменят заедно в рамките на един прозорец за поддръжка.
- Накрая смяната от споделен към собствен пул за останалите домейни, ако паметта на сървъра го позволява.
Преди последното стъпало проверете натоварването на паметта. Plesk посочва, че Dedicated FPM изисква повече памет, и при много уебсайтове съветва наблюдение. Сървър, който след превключването почва да използва swap, става бавен, а оскъдната памет точно при PHP2Shell не е добро състояние.
Как помага PHP SOS конкретно?
- Установяваме кои домейни на Вашия Plesk сървър ползват кой handler и маркираме домейните с Apache модул.
- Превключваме към Dedicated FPM и пренасяме защитните правила от
.htaccessв конфигурацията на nginx, където е нужно. - Задаваме преходни стойности и ограничения за всеки пул и проверяваме, че действат в уеб контекста.
- В рамките на втвърдяването на сървъри деактивираме остарелите 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 съветва при сървъри с много уебсайтове това да се наблюдава.