Krótko: Handler PHP w Plesk określa, jak PHP działa dla strony: jako aplikacja FPM ze wspólną pulą, jako Dedicated FPM z własną pulą dla każdej strony, jako aplikacja FastCGI albo jako moduł Apache (mod_php). Z punktu widzenia bezpieczeństwa Dedicated FPM jest w Linuxie zwykle najlepszym wyborem, a moduł Apache najgorszym. Sam Plesk określa go jako przestarzały lub niebezpieczny, a przy PHP2Shell zespół PHP widzi największe ryzyko właśnie przy mod_php.
Dlaczego handler to więcej niż kwestia wydajności
W Plesk dla każdej strony wybierają Państwo wersję PHP i handler. Wielu traktuje handler jako szczegół dotyczący wydajności i pamięci. Decyduje on jednak także o tym, jak mocno strony są od siebie oddzielone, gdzie działają ustawienia bezpieczeństwa i które procesy trzeba po aktualizacji zrestartować.
Po PHP2Shell wybór ten nabiera konkretnego znaczenia. Luki CVE-2026-109618 i CVE-2026-109619 dotyczą wszystkich popularnych trybów pracy, ale zespół PHP ocenia ryzyko przy mod_php najwyżej. Kto na swoim serwerze Plesk nadal prowadzi domeny z modułem Apache, powinien to teraz zmienić. Jak sprawdzać wersje i je łatać, opisuje strona Serwer Plesk: sprawdzanie i łatanie wersji PHP; tutaj chodzi o wybór trybu pracy.
Handlery PHP w Plesk w skrócie
Poniższe zestawienie opiera się na dokumentacji Plesk dla Plesk Obsidian, uzupełnionej o punkt widzenia bezpieczeństwa. W Linuxie handlery FPM mogą według Plesk być obsługiwane opcjonalnie przez Apache lub nginx, FastCGI zawsze przez Apache.
| Handler | Obsługiwany przez | Izolacja | Zalecenie według Plesk | Punkt widzenia bezpieczeństwa |
|---|---|---|---|---|
| Dedicated FPM application | Apache lub nginx | własna pula dla każdej strony | Linux z hostingiem współdzielonym | najlepsze rozdzielenie, własne wartości dla każdej puli |
| FPM application | Apache lub nginx | wspólna pula dla wersji PHP | dedykowane serwery z Linuxem | wadliwa strona może zakłócać inne z tą samą wersją |
| FastCGI application | Apache (Linux) | trwałe procesy, dobre rozdzielenie | serwery z Windowsem | solidny, w Linuxie zwykle zastąpiony przez FPM |
| Apache module (mod_php) | Apache | PHP w procesie serwera WWW | niezalecany | najwyższe ryzyko PHP2Shell według zespołu PHP |
| CGI application | Apache | nowy proces dla każdego żądania | niezalecany | przestarzały |
Tło samych trybów pracy wyjaśniają strony PHP-FPM wyjaśnione i Dlaczego mod_php niesie najwyższe ryzyko.
Wspólna czy własna pula?
Różnica między FPM a Dedicated FPM bywa niedoceniana. Przy zwykłym handlerze FPM wszystkie strony z tą samą wersją PHP dzielą według Plesk jedną pulę procesów. Oszczędza to pamięć, ale oznacza też: strona sprawiająca problemy może pociągnąć za sobą wszystkie inne z tą samą wersją, a wspólna pamięć podręczna jest współdzielona.
Dedicated FPM daje każdej stronie własną pulę. Według Plesk poprawia to izolację i wydajność, ale kosztuje więcej pamięci. Z punktu widzenia bezpieczeństwa własna pula jest podstawą, by ustawiać takie wartości jak open_basedir, limity pamięci czy limity uploadu osobno dla każdej strony. Jak konsekwentnie rozdzielać pule, opisuje artykuł Izolowanie pul PHP-FPM dla każdej strony.
nginx czy Apache: pułapka .htaccess
Jeśli wybiorą Państwo handler obsługiwany przez nginx, zmienia się coś zasadniczego: według Plesk te handlery ignorują plik .htaccess. To, co w nim stoi, przestaje działać.
To kwestia bezpieczeństwa. Wiele aplikacji i administratorów umieszcza reguły ochronne w .htaccess, na przykład zakaz wykonywania plików PHP w katalogach uploadu lub blokady plików konfiguracyjnych. Po przejściu na nginx reguły te po cichu tracą moc. Dlatego przed zmianą proszę sprawdzić, jakie reguły ochronne stoją w .htaccess, i przenieść je do konfiguracji nginx domeny.
Zmiana handlera to zmiana konfiguracji bezpieczeństwa. Proszę po niej celowo sprawdzić, czy zablokowane ścieżki nadal są zablokowane, a nie tylko, czy ładuje się strona główna.
Sprawdzanie i przestawianie handlera
Najpierw proszę uzyskać przegląd, które domeny używają którego handlera. Polecenia tylko odczytują dane.
# Wszystkie zarejestrowane handlery z ID, wersją i typem
plesk bin php_handler --list
# Domeny, które używają określonego handlera (ID z listy)
plesk bin php_handler --get-usage -id <handler-id>
# Czy PHP działa w procesie Apache? (Debian/Ubuntu: apache2ctl, rodzina RHEL: httpd)
apache2ctl -M 2>/dev/null | grep -i php
Przy przestawianiu proszę postępować domena po domenie:
- Zebrać reguły ochronne z
.htaccess, jeśli nowy handler jest obsługiwany przez nginx. - Ustawić dla nowego handlera wartości przejściowe przeciw PHP2Shell, na przykład
session.upload_progress.enabled=0. W FPM trafiają one jakophp_admin_valuedo dodatkowych dyrektyw puli, w FastCGI działają inne drogi. - Zmienić handler w ustawieniach PHP domeny, najlepiej najpierw na kopii.
- Przetestować funkcje i sprawdzić, czy domena jest obsługiwana przez procesy z aktualnym kodem.
- Jeśli moduł Apache nie jest już używany przez żadną domenę, dezaktywować handler.
W jakiej kolejności przestawiać?
Na rozrośniętym serwerze Plesk rzadko da się wszystko przestawić w jeden dzień. Kolejność według ryzyka pomaga sensownie wykorzystać skąpy czas:
- Najpierw domeny z modułem Apache, ponieważ tam ryzyko ze strony PHP2Shell jest według zespołu PHP najwyższe, a Plesk i tak odradza.
- Potem domeny z wrażliwymi danymi, na przykład sklepy, portale klientów lub formularze z danymi zdrowotnymi albo umownymi. Tu własna pula opłaca się szczególnie.
- Następnie domeny na starych wersjach PHP, które i tak trzeba przestawić. Handler i wersję można zmienić razem w jednym oknie serwisowym.
- Na końcu zmiana ze wspólnej na własną pulę dla pozostałych domen, o ile pamięć serwera na to pozwala.
Przed ostatnim stopniem proszę sprawdzić wykorzystanie pamięci. Plesk zwraca uwagę, że Dedicated FPM potrzebuje więcej pamięci, i przy wielu stronach zaleca monitorowanie. Serwer, który po przestawieniu zaczyna korzystać ze swapu, staje się wolny, a skąpa pamięć w przypadku PHP2Shell to nie jest dobry stan.
Jak konkretnie pomaga PHP SOS?
- Ustalamy, które domeny na Państwa serwerze Plesk używają którego handlera, i oznaczamy domeny z modułem Apache.
- Przestawiamy na Dedicated FPM i przenosimy reguły ochronne z
.htaccessdo konfiguracji nginx, gdzie to konieczne. - Ustawiamy wartości przejściowe i limity dla każdej puli oraz sprawdzamy, czy działają w kontekście WWW.
- W ramach utwardzania serwerów dezaktywujemy przestarzałe handlery i dokumentujemy konfigurację.
Częste pytania
Jakiego handlera PHP zaleca Plesk?
Według dokumentacji Plesk zalecanym handlerem na dedykowanych serwerach z Linuxem jest FPM, na serwerach z Linuxem do hostingu współdzielonego Dedicated FPM, a na serwerach z Windowsem FastCGI. Moduł Apache, CGI i ISAPI Plesk określa jako mocno przestarzałe lub niebezpieczne.
Dlaczego handler moduł Apache jest po PHP2Shell szczególnie krytyczny?
Handler odpowiada mod_php. Zespół PHP ocenia ryzyko PHP2Shell przy mod_php najwyżej, ponieważ pokazano tam exploit, zanim zacznie działać kod aplikacji. Poza tym sam Plesk odradza ten handler.
Co zmienia się, gdy PHP jest obsługiwane przez nginx zamiast Apache?
Według Plesk handlery obsługiwane przez nginx ignorują plik .htaccess. Reguły bezpieczeństwa zapisane tam, na przykład blokady PHP w katalogach uploadu, przestają wtedy działać i trzeba je przenieść do reguł nginx.
Czy po zmianie handlera muszę zrestartować PHP?
Po zmianie proszę sprawdzić, jakie procesy PHP działają dla domeny i od kiedy. W Dedicated FPM domena otrzymuje własną pulę. Stary proces z przestarzałym kodem nie powinien już po tym obsługiwać domeny.
Czy Dedicated FPM jest zawsze najlepszym wyborem?
Pod względem izolacji tak, ponieważ każda strona otrzymuje własną pulę. Ceną jest większe zapotrzebowanie na pamięć. Plesk radzi monitorować przy tym serwery z wieloma stronami.