# Plesk: zrozumieć handlery PHP (FPM, FastCGI, moduł Apache)

> Handlery PHP w Plesk w porównaniu: FPM, Dedicated FPM, FastCGI i moduł Apache z punktu widzenia bezpieczeństwa, z uwagami o PHP2Shell, nginx i .htaccess.

Źródło: https://phpsos.de/pl/blog/plesk-php-handler/  
Stan: 25.10.2026  
Dostawca: PHP SOS, Pomoc awaryjna PHP i bezpieczeństwo serwerów. Natychmiastowa pomoc przez WhatsApp: https://wa.me/491736494914?text=Dzie%C5%84%20dobry%2C%20PHP%20SOS%2C%20potrzebujemy%20pomocy%20z%20naszym%20serwerem%20PHP.%20Firma%3A%20%E2%80%A6%20Strona%20internetowa%3A%20%E2%80%A6

**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](https://phpsos.de/pl/server/plesk/); 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](https://phpsos.de/pl/php/php-fpm-erklaert/) i [Dlaczego mod_php niesie najwyższe ryzyko](https://phpsos.de/pl/php2shell/mod-php-risiko/).

## 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](https://phpsos.de/pl/blog/php-fpm-pools-isolieren/).

## 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.

> **Ważne:**
> 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.

```bash
# 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:

1. Zebrać reguły ochronne z `.htaccess`, jeśli nowy handler jest obsługiwany przez nginx.
2. Ustawić dla nowego handlera wartości przejściowe przeciw PHP2Shell, na przykład `session.upload_progress.enabled=0`. W FPM trafiają one jako `php_admin_value` do dodatkowych dyrektyw puli, w FastCGI działają inne drogi.
3. Zmienić handler w ustawieniach PHP domeny, najlepiej najpierw na kopii.
4. Przetestować funkcje i sprawdzić, czy domena jest obsługiwana przez procesy z aktualnym kodem.
5. 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 `.htaccess` do 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](https://phpsos.de/pl/leistungen/server-haertung/) 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.

## Źródła

- [Dokumentacja Plesk: Choosing the PHP Handler](https://docs.plesk.com/en-US/obsidian/administrator-guide/75145/)
- [Dokumentacja Plesk: php_handler](https://docs.plesk.com/en-US/obsidian/cli-linux/using-command-line-utilities/php_handler-php-handlers.72490/)
- [php.net: komunikaty bezpieczeństwa](https://www.php.net/)