# Plesk: razumjeti PHP handlere (FPM, FastCGI, Apache modul)

> Plesk PHP handleri u usporedbi: FPM, Dedicated FPM, FastCGI i Apache modul sa sigurnosnog gledišta, uz napomene o PHP2Shellu, nginxu i .htaccessu.

Izvor: https://phpsos.de/hr/blog/plesk-php-handler/  
Stanje: 25.10.2026  
Pružatelj: PHP SOS, PHP hitna pomoć i sigurnost poslužitelja. Hitna pomoć putem WhatsAppa: https://wa.me/491736494914?text=Pozdrav%20PHP%20SOS%2C%20trebamo%20pomo%C4%87%20s%20na%C5%A1im%20PHP%20poslu%C5%BEiteljem.%20Tvrtka%3A%20%E2%80%A6%20Web-stranica%3A%20%E2%80%A6

**Ukratko:** Plesk PHP handler određuje kako PHP radi za web-stranicu: kao FPM aplikacija sa zajedničkim poolom, kao Dedicated FPM s vlastitim poolom po web-stranici, kao FastCGI aplikacija ili kao Apache modul (mod_php). Sa sigurnosnog gledišta Dedicated FPM je na Linuxu obično najbolji izbor, a Apache modul najlošiji. Sam ga Plesk naziva zastarjelim odnosno nesigurnim, a kod PHP2Shella PHP tim najviši rizik vidi upravo kod mod_php-a.

## Zašto je handler više od pitanja performansi

U Plesku za svaku web-stranicu birate PHP verziju i handler. Mnogi handler tretiraju kao detalj za performanse i memoriju. No on odlučuje i o tome koliko su web-stranice međusobno razdvojene, gdje djeluju sigurnosne postavke i koje procese treba ponovno pokrenuti nakon ažuriranja.

Nakon PHP2Shella taj izbor postaje konkretan. Ranjivosti CVE-2026-109618 i CVE-2026-109619 pogađaju sve uobičajene načine rada, ali PHP tim rizik kod mod_php-a ocjenjuje najvišim. Tko na svom Plesk poslužitelju još vodi domene s Apache modulom, trebao bi to sada promijeniti. Kako provjeriti verzije i zakrpati ih, opisuje stranica [Plesk poslužitelj: provjera i zakrpanje PHP verzija](https://phpsos.de/hr/server/plesk/); ovdje je riječ o izboru načina rada.

## Plesk PHP handleri ukratko

Sljedeći pregled temelji se na Plesk dokumentaciji za Plesk Obsidian, dopunjenoj sigurnosnim gledištem. Prema Pleskovim podacima na Linuxu se FPM handleri mogu isporučivati po izboru preko Apachea ili nginxa, a FastCGI uvijek preko Apachea.

| Handler | Isporučuje se preko | Izolacija | Preporuka prema Pleskovim podacima | Sigurnosno gledište |
|---|---|---|---|---|
| Dedicated FPM application | Apache ili nginx | vlastiti pool po web-stranici | Linux sa zajedničkim hostingom | najbolje razdvajanje, vlastite vrijednosti po poolu |
| FPM application | Apache ili nginx | zajednički pool po PHP verziji | namjenski Linux poslužitelji | neispravna web-stranica može smetati drugima s istom verzijom |
| FastCGI application | Apache (Linux) | trajni procesi, dobro razdvajanje | Windows poslužitelji | solidno, na Linuxu ga uglavnom zamijenio FPM |
| Apache module (mod_php) | Apache | PHP u procesu web-poslužitelja | ne preporučuje se | najviši rizik od PHP2Shella prema PHP timu |
| CGI application | Apache | novi proces po zahtjevu | ne preporučuje se | zastarjelo |

Pozadinu samih načina rada objašnjavaju stranice [PHP-FPM objašnjen](https://phpsos.de/hr/php/php-fpm-erklaert/) i [Zašto mod_php nosi najviši rizik](https://phpsos.de/hr/php2shell/mod-php-risiko/).

## Zajednički ili vlastiti pool?

Razlika između FPM-a i Dedicated FPM-a često se podcjenjuje. Kod običnog FPM handlera sve web-stranice s istom PHP verzijom prema Pleskovim podacima dijele jedan pool procesa. To štedi memoriju, ali znači i ovo: web-stranica koja stvara probleme može povući sve ostale s istom verzijom, a zajednička predmemorija se dijeli.

Dedicated FPM svakoj web-stranici daje vlastiti pool. Prema Pleskovim podacima to poboljšava izolaciju i performanse, ali troši više memorije. Sa sigurnosnog gledišta vlastiti je pool osnova da se postavke poput `open_basedir`, ograničenja memorije ili ograničenja prijenosa postave odvojeno po web-stranici. Kako dosljedno razdvojiti poolove, opisuje članak [Izolirati PHP-FPM poolove po web-stranici](https://phpsos.de/hr/blog/php-fpm-pools-isolieren/).

## nginx ili Apache: zamka .htaccess

Odaberete li handler koji se isporučuje preko nginxa, mijenja se nešto bitno: prema Pleskovim podacima ti handleri ignoriraju datoteku `.htaccess`. Što u njoj piše, više ne djeluje.

To je sigurnosna tema. Mnoge aplikacije i administratori zaštitna pravila drže u `.htaccess`, primjerice zabranu izvršavanja PHP datoteka u direktorijima za prijenose ili blokade konfiguracijskih datoteka. Nakon prelaska na nginx ta pravila tiho prestaju vrijediti. Zato prije promjene provjerite koja se zaštitna pravila nalaze u `.htaccess` i prenesite ih u nginx konfiguraciju domene.

> **Važno:**
> Promjena handlera je promjena sigurnosne konfiguracije. Nakon nje ciljano testirajte jesu li blokirani putovi i dalje blokirani, a ne samo učitava li se početna stranica.

## Provjeriti i prebaciti handler

Najprije steknite pregled koje domene koriste koji handler. Naredbe samo čitaju.

```bash
# Svi registrirani handleri s ID-om, verzijom i tipom
plesk bin php_handler --list

# Domene koje koriste određeni handler (ID iz popisa)
plesk bin php_handler --get-usage -id <handler-id>

# Radi li PHP u Apacheovu procesu? (Debian/Ubuntu: apache2ctl, RHEL obitelj: httpd)
apache2ctl -M 2>/dev/null | grep -i php
```

Za prebacivanje postupajte domenu po domenu:

1. Zabilježiti zaštitna pravila iz `.htaccess`, ako se novi handler isporučuje preko nginxa.
2. Za novi handler postaviti privremene vrijednosti protiv PHP2Shella, primjerice `session.upload_progress.enabled=0`. Kod FPM-a idu kao `php_admin_value` u dodatne direktive poola, a kod FastCGI-ja djeluju drugi putovi.
3. Promijeniti handler u PHP postavkama domene, po mogućnosti najprije na kopiji.
4. Testirati funkcije i provjeriti poslužuju li domenu procesi s aktualnim kodom.
5. Ako Apache modul više ne koristi nijedna domena, deaktivirati handler.

## Kojim redoslijedom prebacivati?

Na dugo rastućem Plesk poslužitelju rijetko se sve može prebaciti u jednom danu. Redoslijed prema riziku pomaže smisleno iskoristiti oskudno vrijeme:

- **Najprije domene s Apache modulom**, jer je tamo rizik od PHP2Shella prema PHP timu najviši, a Plesk ionako odvraća.
- **Zatim domene s osjetljivim podacima**, primjerice shopovi, portali za klijente ili obrasci sa zdravstvenim ili ugovornim podacima. Ovdje se vlastiti pool osobito isplati.
- **Potom domene na starim PHP verzijama**, koje se ionako moraju prebaciti. Handler i verzija mogu se zajedno promijeniti u jednom servisnom prozoru.
- **Na kraju prelazak sa zajedničkog na vlastiti pool** za preostale domene, ako memorija poslužitelja to dopušta.

Prije posljednje faze provjerite iskorištenost memorije. Plesk upozorava da Dedicated FPM treba više memorije i kod mnogo web-stranica savjetuje nadzor. Poslužitelj koji nakon prebacivanja počne koristiti swap postaje spor, a oskudna memorija upravo kod PHP2Shella nije dobro stanje.

## Kako PHP SOS konkretno pomaže?

- Bilježimo koje domene na Vašem Plesk poslužitelju koriste koji handler i označavamo domene s Apache modulom.
- Prebacujemo na Dedicated FPM i, gdje je potrebno, prenosimo zaštitna pravila iz `.htaccess` u nginx konfiguraciju.
- Postavljamo privremene vrijednosti i ograničenja po poolu te provjeravamo da djeluju u web kontekstu.
- U okviru [ojačavanja poslužitelja](https://phpsos.de/hr/leistungen/server-haertung/) deaktiviramo zastarjele handlere i dokumentiramo konfiguraciju.


## Česta pitanja

**Koji PHP handler preporučuje Plesk?**  
Prema Plesk dokumentaciji FPM je preporučeni handler na namjenskim Linux poslužiteljima, Dedicated FPM na Linux poslužiteljima za zajednički hosting, a FastCGI na Windows poslužiteljima. Apache modul, CGI i ISAPI Plesk naziva izrazito zastarjelima odnosno nesigurnima.

**Zašto je handler Apache modul nakon PHP2Shella osobito kritičan?**  
Handler odgovara mod_php-u. PHP tim rizik od PHP2Shella ocjenjuje najvišim upravo kod mod_php-a jer je tamo pokazan exploit prije nego što se izvrši kod aplikacije. Uz to i sam Plesk odvraća od tog handlera.

**Što se mijenja ako se PHP isporučuje preko nginxa umjesto Apachea?**  
Prema Pleskovim podacima handleri koji se isporučuju preko nginxa ignoriraju datoteku .htaccess. Sigurnosna pravila koja su tamo, primjerice zabrane PHP-a u direktorijima za prijenose, tada više ne djeluju i moraju se prenijeti u nginx pravila.

**Moram li nakon promjene handlera ponovno pokrenuti PHP?**  
Nakon promjene provjerite koji PHP procesi rade za domenu i od kada. Kod Dedicated FPM-a domena dobiva vlastiti pool. Stari proces sa zastarjelim kodom nakon toga više ne bi smio raditi za domenu.

**Je li Dedicated FPM uvijek najbolji izbor?**  
Za izolaciju da, jer svaka web-stranica dobiva vlastiti pool. Cijena je veća potrošnja memorije. Plesk savjetuje da se poslužitelji s mnogo web-stranica pritom nadziru.

## Izvori

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