Situația actuală: PHP2Shell. Două vulnerabilități critice PHP (CVSS 9.2) permit cod malițios fără autentificare. Patchuri din 21.10.2026.Ce este de făcut acum →

PHP-FPM explicat: managerul de procese, pool-uri și workeri

PHP-FPM rulează PHP ca serviciu separat, cu pool-uri și workeri. Cum funcționează modelul de procese, ce directive contează și de ce workerii trebuie reporniți după actualizări.

Stadiu 5 min de cititCunoștințe PHP

Pe scurt: PHP-FPM (FastCGI Process Manager) rulează PHP ca serviciu separat, alături de serverul web. Un proces master administrează pool-uri, iar fiecare pool pornește workeri care prelucrează cererile prin FastCGI. Pool-urile pot fi operate pentru fiecare site cu utilizator propriu, limite proprii și setări PHP blocate. Deoarece workerii prelucrează multe cereri una după alta, după o actualizare PHP toți trebuie reporniți.

Ce este PHP-FPM?

Manualul PHP descrie FPM ca implementarea FastCGI principală a PHP, cu funcții utile mai ales pentru site-urile foarte solicitate. FPM a fost inclus în PHP 5.3.3 ca SAPI separat, deci ca mod de operare propriu. Numele lui SAPI este fpm-fcgi.

Diferența față de mod_php: PHP nu rulează în serverul web, ci ca serviciu separat. Nginx, Apache sau un alt server web transmite cererile PHP prin protocolul FastCGI și primește înapoi răspunsul gata făcut. Serverul web și PHP pot fi astfel repornite, configurate și securizate independent unul de celălalt. Cum funcționează FastCGI în principiu găsiți la CGI și FastCGI.

Master, pool-uri și workeri: modelul de procese

PHP-FPM are trei niveluri:

  1. Procesul master: citește configurația, deschide socket-urile și pornește sau oprește workeri. El însuși nu execută cod de aplicație.
  2. Pool-uri: Fiecare pool are un nume, un socket sau port propriu, un utilizator Unix propriu și setări PHP proprii. Manualul menționează explicit uid, gid, chroot, mediu și php.ini diferite pentru fiecare pool.
  3. Workeri: procese ale unui pool care primesc și execută cereri. Un worker prelucrează multe cereri una după alta, înainte de a fi înlocuit.

Câți workeri rulează stabilește managerul de procese prin directiva pm:

Mod Comportament Directive importante
static număr fix de workeri pm.max_children
dynamic workeri între o limită inferioară și una superioară pm.start_servers, pm.min_spare_servers, pm.max_spare_servers
ondemand workeri doar la nevoie, eliminați după inactivitate pm.process_idle_timeout (implicit 10s)

pm.max_children limitează în toate modurile numărul de cereri simultane. pm.max_requests înlocuiește un worker după un număr fix de cereri; valoarea implicită 0 înseamnă nelimitat.

Ce mod se potrivește depinde de încărcare. static ține mereu pregătit același număr de workeri și este potrivit pentru aplicații folosite uniform de intens, cu suficientă memorie. dynamic este un compromis pentru majoritatea site-urilor. ondemand economisește memorie pe serverele cu multe site-uri mici, pentru că pool-urile fără vizitatori nu ocupă workeri; în schimb, prima cerere după o pauză durează puțin mai mult. Un pm.max_children setat prea sus poate duce serverul la lipsă de memorie în vârfurile de încărcare, unul setat prea jos duce la timpi de așteptare și la mesaje de eroare ale serverului web.

Un pool cu setări de bază sigure

Un exemplu de pool propriu pentru fiecare site, cu directive din manualul PHP. Căile și valorile sunt exemple:

; /etc/php/8.3/fpm/pool.d/kunde-a.conf
[kunde-a]
user = kunde-a
group = kunde-a

listen = /run/php/kunde-a.sock
listen.owner = www-data
listen.group = www-data
listen.mode = 0660

pm = ondemand
pm.max_children = 10
pm.process_idle_timeout = 10s

request_terminate_timeout = 60s
security.limit_extensions = .php
clear_env = yes

php_admin_value[open_basedir] = /var/www/kunde-a:/tmp
php_admin_flag[session.upload_progress.enabled] = off
php_admin_value[error_log] = /var/log/php/kunde-a.error.log

Potrivit manualului, valorile setate prin php_value și php_flag pot fi modificate în timpul execuției cu ini_set(), cele setate prin php_admin_value și php_admin_flag, în schimb, nu. security.limit_extensions este implicit .php .phar și stabilește ce extensii de fișier execută FPM drept script principal. clear_env = yes este valoarea implicită și golește mediul workerilor.

Pentru monitorizare există o pagină de stare prin pm.status_path și o pagină de ping prin ping.path. Ambele ar trebui să fie accesibile doar intern. Cererile lente sunt înregistrate de FPM cu backtrace dacă sunt setate request_slowlog_timeout și slowlog.

Important

Manualul PHP avertizează: cine poate deschide o conexiune FastCGI către PHP-FPM controlează configurația cererii și poate astfel executa orice cod. PHP-FPM nu trebuie să fie niciodată accesibil dintr-o rețea de neîncredere. Folosiți un socket Unix sau listen.allowed_clients.

Ce rol are PHP-FPM la PHP2Shell?

PHP-FPM face parte din modurile de operare afectate. Modelul de procese devine deosebit de evident la CVE-2026-109619: starea internă aferentă cererii poate persista după eliberarea memoriei, iar o cerere ulterioară în același worker o poate folosi înainte să fie resetată. Acest lucru este posibil doar pentru că workerii prelucrează multe cereri una după alta.

Din asta rezultă trei obligații:

  1. Instalarea actualizării: PHP 8.5.12, 8.4.27, 8.3.36 sau 8.2.35, respectiv un backport confirmat al distribuției.
  2. Repornirea tuturor workerilor: Fișierele noi de pe disc nu schimbă nimic cât timp rulează workeri vechi. Aceasta se aplică fiecărei versiuni FPM instalate și fiecărui pool. Comenzile se află la Repornirea PHP-FPM și a tuturor workerilor.
  3. Setarea blocată a valorilor provizorii: Măsurile de la php.net, de exemplu session.upload_progress.enabled=0, aparțin pool-ului prin php_admin_value sau php_admin_flag, nu în .user.ini.

Separarea în pool-uri nu înlocuiește o actualizare, dar limitează paguba: dacă fiecare site rulează sub un utilizator propriu, un atacator nu ajunge automat la fișierele celorlalte după o intruziune. Cum arată concret descrie Izolarea pool-urilor PHP-FPM pentru fiecare site; integrarea în Nginx se află la Securizarea Nginx cu PHP-FPM.

Cum ajută PHP SOS concret?

  • Inventarierea pool-urilor: Listăm toate versiunile FPM, pool-urile, utilizatorii și socket-urile serverului dumneavoastră.
  • Patch și repornire: Actualizăm PHP și dovedim prin orele de pornire că nu mai rulează niciun worker vechi.
  • Separarea pool-urilor: În cadrul întăririi serverului configurăm pentru fiecare site un pool cu utilizator propriu și setări blocate.
  • Verificarea accesibilității: Controlăm că socket-urile FastCGI și paginile de stare nu sunt accesibile din exterior.

Întrebări frecvente

Ce înseamnă FPM?

FPM înseamnă FastCGI Process Manager. Manualul PHP îl descrie ca implementarea FastCGI principală a PHP, cu funcții utile mai ales pentru site-urile foarte solicitate. A fost inclus în PHP 5.3.3.

Care este diferența dintre pool și worker?

Un pool este un grup de procese worker cu configurație comună: utilizator, socket, limite și setări PHP. Un worker este un singur proces care prelucrează cererile una după alta. Un server poate avea multe pool-uri, de exemplu câte unul pentru fiecare site.

Ar trebui PHP-FPM să fie accesibil prin TCP sau printr-un socket Unix?

Dacă serverul web rulează pe aceeași gazdă, manualul PHP recomandă un socket Unix. La TCP trebuie setat listen.allowed_clients, altfel orice adresă se poate conecta. Un port FastCGI accesibil deschis permite, potrivit manualului, execuția oricărui cod.

Protejează pm.max_requests împotriva unor vulnerabilități precum PHP2Shell?

Nu. pm.max_requests înlocuiește un worker după un număr fix de cereri și ajută mai ales împotriva scurgerilor de memorie din extensii. Împotriva unei vulnerabilități din interpretor ajută doar actualizarea, urmată de repornirea tuturor workerilor.

Surse

Contact imediat

Fiecare oră contează. Scrieți-ne acum.

Descrieți pe scurt sistemul, versiunea PHP și ce ați observat. Ne vom face auziți, clarificăm situația și lucrăm la distanță până când incidentul este încheiat și documentat.

Ajutor imediat