# Plesk: a PHP-handlerek megértése (FPM, FastCGI, Apache-modul)

> Plesk PHP-handler összehasonlítás: FPM, Dedicated FPM, FastCGI és Apache-modul biztonsági szemmel, PHP2Shell-, nginx- és .htaccess-tudnivalókkal.

Forrás: https://phpsos.de/hu/blog/plesk-php-handler/  
Állapot: 2026. 10. 25.  
Szolgáltató: PHP SOS, PHP-vészhelyzeti segítség és szerverbiztonság. Azonnali segítség WhatsAppon: https://wa.me/491736494914?text=%C3%9Cdv%C3%B6zl%C3%B6m%2C%20PHP%20SOS%21%20Seg%C3%ADts%C3%A9gre%20van%20sz%C3%BCks%C3%A9g%C3%BCnk%20a%20PHP-szerver%C3%BCnkkel.%20C%C3%A9g%3A%20%E2%80%A6%20Weboldal%3A%20%E2%80%A6

**Röviden:** A Plesk PHP-handlere határozza meg, hogyan fut a PHP egy weboldalhoz: FPM-alkalmazásként közös poolban, Dedicated FPM-ként weboldalankénti saját poolban, FastCGI-alkalmazásként vagy Apache-modulként (mod_php). Biztonsági szempontból Linux alatt többnyire a Dedicated FPM a legjobb választás, az Apache-modul a legrosszabb. A Plesk maga is elavultnak, illetve nem biztonságosnak nevezi, és a PHP2Shell esetében a PHP-csapat éppen a mod_php-nál látja a legnagyobb kockázatot.

## Miért több a handler teljesítménykérdésnél

A Pleskben minden weboldalhoz PHP-verziót és handlert választ. Sokan a handlert a teljesítmény és a memória részletkérdésének tekintik. Pedig az is eldönti, mennyire vannak elválasztva egymástól a weboldalak, hol hatnak a biztonsági beállítások, és mely folyamatokat kell frissítés után újraindítani.

A PHP2Shell után ez a választás konkréttá válik. A CVE-2026-109618 és CVE-2026-109619 rések az összes elterjedt üzemmódot érintik, a PHP-csapat azonban a mod_php esetében értékeli a legmagasabbra a kockázatot. Aki a Plesk-szerverén még Apache-modullal üzemeltet domaineket, most változtasson ezen. Hogyan ellenőrzi és javítja a verziókat, azt a [Plesk-szerver: PHP-verziók ellenőrzése és javítása](https://phpsos.de/hu/server/plesk/) oldal írja le; itt az üzemmód kiválasztásáról van szó.

## A Plesk PHP-handlerei áttekintésben

Az alábbi áttekintés a Plesk Obsidian Plesk-dokumentációján alapul, kiegészítve a biztonsági szemponttal. Linux alatt az FPM-handlerek a Plesk szerint tetszés szerint Apache-on vagy nginxen keresztül szolgálhatók ki, a FastCGI mindig Apache-on keresztül.

| Handler | Kiszolgálás | Izoláció | A Plesk ajánlása | Biztonsági szempont |
|---|---|---|---|---|
| Dedicated FPM application | Apache vagy nginx | weboldalankénti saját pool | Linux megosztott tárhellyel | a legjobb elválasztás, poolonként saját értékek |
| FPM application | Apache vagy nginx | PHP-verziónként közös pool | dedikált Linux-szerverek | egy hibás weboldal zavarhatja a többit ugyanazon a verzión |
| FastCGI application | Apache (Linux) | tartós folyamatok, jó elválasztás | Windows-szerverek | megbízható, Linux alatt többnyire az FPM váltotta fel |
| Apache module (mod_php) | Apache | PHP a webszerver folyamatában | nem ajánlott | a PHP-csapat szerint a legmagasabb PHP2Shell-kockázat |
| CGI application | Apache | új folyamat minden kéréshez | nem ajánlott | elavult |

Az üzemmódok hátterét a [A PHP-FPM magyarázata](https://phpsos.de/hu/php/php-fpm-erklaert/) és a [Miért a mod_php viseli a legmagasabb kockázatot](https://phpsos.de/hu/php2shell/mod-php-risiko/) oldal ismerteti.

## Közös vagy saját pool?

Az FPM és a Dedicated FPM közötti különbséget gyakran alábecsülik. A normál FPM-handlernél a Plesk szerint az azonos PHP-verziójú összes weboldal egy folyamat-poolon osztozik. Ez memóriát takarít meg, de azt is jelenti: egy problémát okozó weboldal magával rántja az összes többit ugyanazon a verzión, és a közös gyorsítótár is osztott.

A Dedicated FPM minden weboldalnak saját poolt ad. A Plesk szerint ez javítja az izolációt és a teljesítményt, de több memóriát igényel. Biztonsági szempontból a saját pool az alapja annak, hogy az olyan beállításokat, mint az `open_basedir`, a memóriakorlátok vagy a feltöltési limitek, weboldalanként külön lehessen megadni. Hogyan választja el következetesen a poolokat, azt a [PHP-FPM-poolok izolálása weboldalanként](https://phpsos.de/hu/blog/php-fpm-pools-isolieren/) cikk írja le.

## nginx vagy Apache: a .htaccess-csapda

Ha nginxen keresztül kiszolgált handlert választ, valami alapvető megváltozik: a Plesk szerint ezek a handlerek figyelmen kívül hagyják a `.htaccess` fájlt. Ami ott áll, többé nem hat.

Ez biztonsági téma. Sok alkalmazás és rendszergazda a védelmi szabályokat a `.htaccess` fájlban tartja, például a PHP-fájlok futtatásának tiltását a feltöltési mappákban vagy a konfigurációs fájlok zárolását. Az nginxre váltás után ezek a szabályok csendben hatályukat vesztik. Ellenőrizze ezért a váltás előtt, mely védelmi szabályok szerepelnek a `.htaccess` fájlban, és vigye át őket a domain nginx-konfigurációjába.

> **Fontos:**
> A handler cseréje a biztonsági konfiguráció módosítása. Utána célzottan tesztelje, hogy a lezárt útvonalak továbbra is le vannak-e zárva, és ne csak azt, hogy a nyitóoldal betöltődik-e.

## A handler ellenőrzése és átállítása

Először áttekintést kell szereznie arról, mely domainek melyik handlert használják. A parancsok kizárólag olvasnak.

```bash
# Az összes regisztrált handler azonosítóval, verzióval és típussal
plesk bin php_handler --list

# Egy adott handlert használó domainek (az azonosító a listából)
plesk bin php_handler --get-usage -id <handler-id>

# Fut a PHP az Apache-folyamatban? (Debian/Ubuntu: apache2ctl, RHEL-család: httpd)
apache2ctl -M 2>/dev/null | grep -i php
```

Az átállításnál domainről domainre haladjon:

1. Gyűjtse össze a `.htaccess` védelmi szabályait, ha az új handlert nginxen keresztül szolgálják ki.
2. Állítsa be az új handlerhez a PHP2Shell elleni átmeneti értékeket, például a `session.upload_progress.enabled=0` értéket. FPM esetén ezek `php_admin_value` formában a pool kiegészítő direktívái közé tartoznak, FastCGI esetén más utak hatnak.
3. Váltson handlert a domain PHP-beállításaiban, lehetőleg először egy másolaton.
4. Tesztelje a funkciókat, és ellenőrizze, hogy a domaint aktuális kódú folyamatok szolgálják-e ki.
5. Ha az Apache-modult már egyetlen domain sem használja, kapcsolja ki a handlert.

## Milyen sorrendben állítson át?

Egy kinőtt Plesk-szerveren ritkán lehet mindent egy nap alatt átállítani. A kockázat szerinti sorrend segít a szűkös időt értelmesen felhasználni:

- **Először az Apache-modult használó domainek**, mert ott a PHP-csapat szerint a legnagyobb a PHP2Shell kockázata, és a Plesk amúgy is eltanácsol tőle.
- **Aztán az érzékeny adatokat kezelő domainek**, például webshopok, ügyfélportálok vagy egészségügyi vagy szerződéses adatokat tartalmazó űrlapok. Itt különösen megéri a saját pool.
- **Ezután a régi PHP-verziókon lévő domainek**, amelyeket amúgy is át kell állítani. A handler és a verzió egy karbantartási ablakban együtt cserélhető.
- **Végül a közös poolról a saját poolra váltás** a többi domainnél, ha a szerver memóriája engedi.

Az utolsó lépcső előtt ellenőrizze a memóriakihasználtságot. A Plesk arra figyelmeztet, hogy a Dedicated FPM több memóriát igényel, és sok weboldalnál a figyelést javasolja. Az a szerver, amely az átállítás után memóriát lapoz ki, lassúvá válik, és a szűkös memória éppen a PHP2Shell idején nem jó állapot.

## Hogyan segít konkrétan a PHP SOS?

- Felmérjük, a Plesk-szerverén mely domainek melyik handlert használják, és megjelöljük az Apache-modult használó domaineket.
- Átállítunk Dedicated FPM-re, és a `.htaccess` védelmi szabályait szükség esetén átültetjük az nginx-konfigurációba.
- Poolonként beállítjuk az átmeneti értékeket és korlátokat, és ellenőrizzük, hogy a webes környezetben érvényesülnek.
- A [szerver megerősítése](https://phpsos.de/hu/leistungen/server-haertung/) keretében kikapcsoljuk az elavult handlereket, és dokumentáljuk a konfigurációt.


## Gyakori kérdések

**Melyik PHP-handlert ajánlja a Plesk?**  
A Plesk-dokumentáció szerint az FPM az ajánlott handler dedikált Linux-szervereken, a Dedicated FPM megosztott tárhelyet kiszolgáló Linux-szervereken, a FastCGI pedig Windows-szervereken. Az Apache-modult, a CGI-t és az ISAPI-t a Plesk erősen elavultnak, illetve nem biztonságosnak minősíti.

**Miért különösen kritikus az Apache-modul handler a PHP2Shell után?**  
A handler a mod_php-nak felel meg. A PHP-csapat a PHP2Shell kockázatát a mod_php esetében értékeli a legmagasabbra, mert ott még az alkalmazáskód futása előtt bemutattak egy exploitot. Emellett a Plesk maga is eltanácsol ettől a handlertől.

**Mi változik, ha a PHP-t nginxen keresztül szolgálják ki Apache helyett?**  
A Plesk szerint az nginxen keresztül kiszolgált handlerek figyelmen kívül hagyják a .htaccess fájlt. Az ott szereplő biztonsági szabályok, például a PHP tiltása a feltöltési mappákban, ilyenkor már nem érvényesülnek, és nginx-szabályokká kell átültetni őket.

**Újra kell indítani a PHP-t a handler cseréje után?**  
A csere után ellenőrizze, mely PHP-folyamatok futnak a domainhez, és mióta. Dedicated FPM esetén a domain saját poolt kap. Egy elavult kódú régi folyamat ezután már ne dolgozzon a domainnek.

**A Dedicated FPM mindig a legjobb választás?**  
Az izoláció szempontjából igen, mert minden weboldal saját poolt kap. Ennek ára a nagyobb memóriaigény. A Plesk azt javasolja, hogy sok weboldalt kiszolgáló szervereket ilyenkor figyeljen.

## Források

- [Plesk-dokumentáció: Choosing the PHP Handler](https://docs.plesk.com/en-US/obsidian/administrator-guide/75145/)
- [Plesk-dokumentáció: php_handler](https://docs.plesk.com/en-US/obsidian/cli-linux/using-command-line-utilities/php_handler-php-handlers.72490/)
- [php.net: biztonsági közlemények](https://www.php.net/)