Pe scurt: Handlerul PHP din Plesk stabilește cum rulează PHP pentru un site: ca aplicație FPM cu pool comun, ca Dedicated FPM cu pool propriu pentru fiecare site, ca aplicație FastCGI sau ca modul Apache (mod_php). Din punct de vedere al securității, Dedicated FPM este de obicei cea mai bună alegere pe Linux, iar modulul Apache cea mai proastă. Plesk însuși îl descrie ca depășit, respectiv nesigur, iar la PHP2Shell echipa PHP vede cel mai mare risc tocmai la mod_php.
De ce handlerul este mai mult decât o chestiune de performanță
În Plesk alegeți pentru fiecare site o versiune PHP și un handler. Mulți tratează handlerul ca pe un detaliu de performanță și memorie. El decide însă și cât de puternic sunt separate site-urile între ele, unde acționează setările de securitate și ce procese trebuie repornite după o actualizare.
După PHP2Shell, această alegere devine concretă. Vulnerabilitățile CVE-2026-109618 și CVE-2026-109619 afectează toate modurile de operare uzuale, dar echipa PHP încadrează riscul ca fiind cel mai ridicat la mod_php. Cine mai operează pe serverul Plesk domenii cu modulul Apache ar trebui să schimbe acest lucru acum. Cum verificați și actualizați versiunile descrie pagina Servere Plesk: verificarea și patchul versiunilor PHP; aici este vorba despre alegerea modului de operare.
Handlerii PHP din Plesk pe scurt
Tabelul următor se bazează pe documentația Plesk pentru Plesk Obsidian, completată cu perspectiva securității. Pe Linux, handlerii FPM pot fi serviți, conform Plesk, la alegere prin Apache sau nginx, iar FastCGI întotdeauna prin Apache.
| Handler | Servit prin | Izolare | Recomandare conform Plesk | Perspectiva securității |
|---|---|---|---|---|
| Dedicated FPM application | Apache sau nginx | pool propriu pentru fiecare site | Linux cu shared hosting | cea mai bună separare, valori proprii pentru fiecare pool |
| FPM application | Apache sau nginx | pool comun pentru fiecare versiune PHP | servere Linux dedicate | un site defectuos poate perturba altele cu aceeași versiune |
| FastCGI application | Apache (Linux) | procese permanente, separare bună | servere Windows | solid, pe Linux de obicei înlocuit de FPM |
| Apache module (mod_php) | Apache | PHP în procesul serverului web | nerecomandat | cel mai mare risc PHP2Shell conform echipei PHP |
| CGI application | Apache | proces nou pentru fiecare cerere | nerecomandat | depășit |
Contextul modurilor de operare însele îl explică paginile PHP-FPM explicat și De ce mod_php poartă cel mai mare risc.
Pool comun sau propriu?
Diferența dintre FPM și Dedicated FPM este adesea subestimată. La handlerul FPM obișnuit, toate site-urile cu aceeași versiune PHP își împart, conform Plesk, un pool de procese. Aceasta economisește memorie, dar înseamnă și că un site care face probleme poate trage după el toate celelalte cu aceeași versiune, iar cache-ul comun este partajat.
Dedicated FPM dă fiecărui site un pool propriu. Conform Plesk, aceasta îmbunătățește izolarea și performanța, dar costă mai multă memorie. Din punct de vedere al securității, poolul propriu este baza pentru a seta separat, pentru fiecare site, setări precum open_basedir, limite de memorie sau limite de upload. Cum separați consecvent pool-urile descrie articolul Izolarea pool-urilor PHP-FPM pentru fiecare site.
nginx sau Apache: capcana .htaccess
Dacă alegeți un handler servit prin nginx, se schimbă ceva fundamental: conform Plesk, acești handleri ignoră fișierul .htaccess. Ceea ce se află acolo nu mai acționează.
Aceasta este o problemă de securitate. Multe aplicații și administratori pun reguli de protecție în .htaccess, de exemplu interdicția de a executa fișiere PHP în directoarele de upload sau blocări pentru fișierele de configurare. După trecerea la nginx, aceste reguli sunt scoase din funcțiune în tăcere. Verificați de aceea, înainte de schimbare, ce reguli de protecție se află în .htaccess și transpuneți-le în configurația nginx a domeniului.
O schimbare de handler este o modificare a configurației de securitate. Testați după aceea țintit dacă căile blocate rămân blocate, nu doar dacă se încarcă pagina de start.
Verificarea și schimbarea handlerului
Mai întâi vă faceți o imagine despre ce domenii folosesc ce handler. Comenzile sunt exclusiv de citire.
# Toți handlerii înregistrați cu ID, versiune și tip
plesk bin php_handler --list
# Domenii care folosesc un anumit handler (ID din listă)
plesk bin php_handler --get-usage -id <handler-id>
# Rulează PHP în procesul Apache? (Debian/Ubuntu: apache2ctl, familia RHEL: httpd)
apache2ctl -M 2>/dev/null | grep -i php
Pentru schimbare procedați domeniu cu domeniu:
- Inventariați regulile de protecție din
.htaccess, dacă noul handler este servit prin nginx. - Setați pentru noul handler valorile provizorii împotriva PHP2Shell, de exemplu
session.upload_progress.enabled=0. La FPM ele aparțin, caphp_admin_value, directivelor suplimentare ale pool-ului; la FastCGI acționează alte căi. - Schimbați handlerul în setările PHP ale domeniului, de preferință mai întâi pe o copie.
- Testați funcțiile și verificați dacă domeniul este deservit de procese cu cod actual.
- Dacă modulul Apache nu mai este folosit de niciun domeniu, dezactivați handlerul.
În ce ordine schimbați?
Pe un server Plesk crescut organic, rareori se poate schimba totul într-o singură zi. O ordine după risc ajută la folosirea rațională a timpului limitat:
- Mai întâi domeniile cu modulul Apache, deoarece acolo riscul PHP2Shell este, conform echipei PHP, cel mai ridicat, iar Plesk descurajează oricum.
- Apoi domeniile cu date sensibile, de exemplu magazine, portaluri pentru clienți sau formulare cu date de sănătate sau contractuale. Aici poolul propriu merită în mod deosebit.
- După aceea domeniile pe versiuni PHP vechi, care oricum trebuie mutate. Handlerul și versiunea pot fi schimbate împreună într-o fereastră de mentenanță.
- La urmă trecerea de la poolul comun la cel propriu pentru domeniile rămase, dacă memoria serverului o permite.
Verificați înainte de ultima etapă utilizarea memoriei. Plesk atrage atenția că Dedicated FPM necesită mai multă memorie și recomandă monitorizare la multe site-uri. Un server care după schimbare mută memoria pe disc devine lent, iar memoria insuficientă nu este o stare bună tocmai la PHP2Shell.
Cum ajută PHP SOS concret?
- Inventariem ce domenii de pe serverul dumneavoastră Plesk folosesc ce handler și marcăm domeniile cu modul Apache.
- Trecem la Dedicated FPM și transpunem, acolo unde este nevoie, regulile de protecție din
.htaccessîn configurația nginx. - Setăm valori provizorii și limite pentru fiecare pool și verificăm că acționează în contextul web.
- În cadrul securizării serverului dezactivăm handlerii depășiți și documentăm configurația.
Întrebări frecvente
Ce handler PHP recomandă Plesk?
Conform documentației Plesk, FPM este handlerul recomandat pe serverele Linux dedicate, Dedicated FPM pe serverele Linux pentru shared hosting și FastCGI pe serverele Windows. Modulul Apache, CGI și ISAPI sunt descrise de Plesk drept puternic depășite, respectiv nesigure.
De ce este handlerul modul Apache deosebit de critic după PHP2Shell?
Handlerul corespunde mod_php. Echipa PHP încadrează riscul PHP2Shell ca fiind cel mai ridicat la mod_php, deoarece acolo a fost demonstrat un exploit înainte de rularea codului aplicației. În plus, Plesk însuși descurajează acest handler.
Ce se schimbă dacă PHP este servit prin nginx în loc de Apache?
Conform Plesk, handlerii serviți prin nginx ignoră fișierul .htaccess. Regulile de securitate care se află acolo, de exemplu blocări pentru PHP în directoarele de upload, nu mai acționează și trebuie transpuse în reguli nginx.
Trebuie să repornesc PHP după schimbarea handlerului?
După schimbare, verificați ce procese PHP rulează pentru domeniu și de când. La Dedicated FPM, domeniul primește un pool propriu. Un proces vechi cu cod depășit nu ar trebui să mai lucreze după aceea pentru domeniu.
Este Dedicated FPM întotdeauna cea mai bună alegere?
Pentru izolare, da, deoarece fiecare site primește un pool propriu. Prețul este un necesar mai mare de memorie. Plesk recomandă monitorizarea serverelor cu multe site-uri.