Dacă găzduiești mai multe site-uri WordPress pe același VPS sau server dedicat, una dintre cele mai utile măsuri de bază este să nu le lași să ruleze toate în același context PHP-FPM. Configurația „merge și așa”, cu un singur pool comun, poate părea suficientă la început, dar devine rapid o problemă atunci când un site consumă prea multe resurse, apare o eroare într-un plugin sau trebuie să investighezi un incident.
Documentația oficială PHP arată clar că poți rula mai multe pool-uri PHP-FPM cu setări diferite pentru fiecare. În practică, asta înseamnă că fiecare site WordPress important poate avea propriul utilizator Unix, propriul socket sau propriul port local, propriile loguri și propriile limite de procesare. Rezultatul nu este o „cutie etanșă” în sens absolut: manualul PHP avertizează și că pool-urile nu reprezintă un mecanism complet de securitate, deoarece nu oferă separare totală, iar OPcache rămâne partajat. Totuși, pentru administrarea de zi cu zi, această separare reduce riscul ca o problemă dintr-un site să afecteze imediat toate celelalte.
Primul pas este regula simplă: un site, un pool, un utilizator. În loc să rulezi toate instalările WordPress cu același user al procesului web, creezi câte un utilizator dedicat pentru fiecare proiect și configurezi pool-ul PHP-FPM să ruleze cu acel user și cu grupul lui. În manualul PHP, directivele user și group sunt obligatorii la nivel de pool. Asta ajută la delimitarea permisiunilor pe fișiere și face mai ușoară analiza atunci când un site are erori, consum mare sau fișiere modificate suspect.
Al doilea pas este separarea căii de execuție. Pentru fiecare pool, folosești un socket Unix diferit sau un port local diferit, apoi îl legi explicit de virtual host-ul acelui site. Directive precum listen, listen.owner și listen.group există tocmai pentru acest tip de control. Ideea practică este ca site-ul A să nu trimită cereri PHP în socket-ul site-ului B dintr-o configurație greșită. Tot aici merită păstrate loguri separate pentru fiecare pool, ca să poți vedea rapid ce site generează erori sau procese lente.
Al treilea pas este limitarea resurselor pe site, nu doar pe server. PHP-FPM permite setări per pool pentru pm.max_children, pm.max_requests și request_terminate_timeout. Pe scurt, poți stabili câți workeri PHP poate porni fiecare site, după câte cereri este reciclat un worker și cât poate dura o cerere înainte să fie oprită. Asta nu înlocuiește monitorizarea, dar te ajută să împiedici un magazin WordPress cu un plugin defect să blocheze restul site-urilor din același server.
Al patrulea pas este controlul strict al permisiunilor. WordPress recomandă explicit ca fișierele să fie deținute, în mod normal, de contul tău de utilizator și avertizează că accesul de scriere acordat prea larg este periculos, mai ales în medii shared hosting. În ghidul despre permisiuni, WordPress spune și că directoarele nu ar trebui setate niciodată la 777. Cu alte cuvinte, izolarea prin pool-uri nu ajută prea mult dacă toate directoarele sunt încă deschise excesiv sau dacă mai multe site-uri folosesc aceleași căi de scriere fără control.
Al cincilea pas este reducerea suprafeței de atac din pool. Manualul PHP recomandă clear_env pentru a împiedica variabile arbitrare de mediu să ajungă în procesele worker și security.limit_extensions pentru a limita ce extensii poate interpreta FPM, în mod ideal doar .php. Sunt detalii mai puțin spectaculoase decât numărul de workeri, dar foarte utile când vrei o configurație mai curată și mai predictibilă.
Mai este o idee importantă din documentația WordPress: dacă rulezi mai multe bloguri pe același server, merită să le ții și în baze de date separate, administrate de utilizatori diferiți. Este o măsură de „containment”. Dacă un site este compromis, atacatorului îi este mai greu să se miște lateral spre celelalte proiecte. Același principiu se aplică și la nivelul PHP-FPM: separarea nu garantează invulnerabilitate, dar reduce raza de impact.
Pe scurt, dacă administrezi mai multe site-uri WordPress, configurația minimă sănătoasă este aceasta: pool separat pentru fiecare site, utilizator separat, socket separat, permisiuni stricte, loguri separate și limite realiste pentru procese. Înainte de orice schimbare, fă backup și testează pe un site mai puțin critic. Iar după implementare, verifică dacă actualizările WordPress, încărcările media, cache-ul și joburile programate funcționează corect. Izolarea bună nu înseamnă doar securitate mai bună, ci și depanare mult mai simplă.
