# PHP-FPM explicat: managerul de procese, pool-uri și workeri

> PHP-FPM explicat: cum lucrează master, pool-uri și workeri, ce înseamnă pm static, dynamic și ondemand și ce setări de pool aduc securitate.

Sursa: https://phpsos.de/ro/php/php-fpm-erklaert/  
Stadiu: 25.10.2026  
Furnizor: PHP SOS, Asistență de urgență PHP și securitatea serverelor. Ajutor imediat pe WhatsApp: https://wa.me/491736494914?text=Bun%C4%83%20ziua%2C%20PHP%20SOS%2C%20avem%20nevoie%20de%20ajutor%20cu%20serverul%20nostru%20PHP.%20Firma%3A%20%E2%80%A6%20Site%3A%20%E2%80%A6

**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](https://phpsos.de/ro/php/cgi-und-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:

```ini
; /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](https://phpsos.de/ro/php2shell/php-fpm-neustart/).
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](https://phpsos.de/ro/blog/php-fpm-pools-isolieren/); integrarea în Nginx se află la [Securizarea Nginx cu PHP-FPM](https://phpsos.de/ro/server/nginx-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](https://phpsos.de/ro/leistungen/server-haertung/) 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

- [Manualul PHP: FastCGI Process Manager](https://www.php.net/manual/en/install.fpm.php)
- [Manualul PHP: configurarea FPM](https://www.php.net/manual/en/install.fpm.configuration.php)
- [php.net: lansarea PHP 5.3.3](https://www.php.net/releases/5_3_3.php)
- [php.net: anunțuri de securitate](https://www.php.net/)
