NGINX Unit come alternativa a PHP-FPM? Architettura, rischi e casi d'uso

Stato archiviato e breve sentenza chiara

Al 30 settembre 2026, il verdetto è chiaro: Unità NGINX era in grado di eseguire direttamente applicazioni PHP, accettando connessioni HTTP, terminando le connessioni TLS, fornendo file statici e instradando le richieste. Le sue funzionalità andavano quindi ben oltre quelle di PHP-FPM. Tuttavia, Unit non è una scelta generalmente consigliata per le nuove piattaforme di hosting PHP in produzione, poiché il progetto ufficiale è stato archiviato a partire da ottobre 2025 e non viene più aggiornato.

Ciò non significa che un’installazione Unit esistente diventi immediatamente inutilizzabile. Può continuare a supportare un’applicazione, a condizione che le sue dipendenze, le misure di sicurezza e un percorso di migrazione siano documentati. Un nuovo investimento deve però essere valutato in modo diverso: senza una manutenzione continua del progetto, aumentano i rischi legati alle vulnerabilità di sicurezza, alla disponibilità dei pacchetti, alle nuove versioni del sistema operativo e alla compatibilità futura con PHP.

Quando si fa riferimento alle versioni, è importante operare una chiara distinzione. La documentazione di installazione, ancora disponibile, menziona spesso la versione Unit 1.34.2, mentre è stata pubblicata la versione stabile 1.35.0. Questa versione garantisce, tra l’altro, la compatibilità con PHP 8.5; ciò non implica tuttavia una manutenzione continuativa. Il ramo di sviluppo master A causa del suo stato di "archiviato", questa versione del prodotto non è rilevante ai fini delle decisioni operative.

Differenze tra NGINX, PHP-FPM e Unit

Per prendere una decisione ben fondata, è necessario considerare i singoli elementi separatamente. NGINX È un server web e un proxy inverso: riceve le richieste HTTP, è in grado di fornire contenuti statici e inoltra le richieste dinamiche. PHP-FPM, invece, è un FastCGI Process Manager. Fornisce i worker PHP, ma non si occupa direttamente delle tipiche attività del server web, ovvero l’accettazione delle richieste HTTP e il routing.

Nella struttura classica, una richiesta arriva innanzitutto a NGINX. Se si tratta di un file statico, NGINX può fornirlo immediatamente. Nel caso di uno script PHP, NGINX trasmette i parametri FastCGI necessari a un pool PHP-FPM; un worker libero esegue il codice e restituisce la risposta tramite NGINX. La dimensione del pool e la modalità di processo in PHP-FPM sono gestite tramite file di configurazione in formato php.ini.

Unit, al contrario, era un Server delle applicazioni con listener, route, distribuzione statica e tempi di esecuzione del codice in un modello di configurazione JSON. Un'applicazione PHP viene integrata come tipo di applicazione; Unit è quindi in grado di mappare il percorso della richiesta all'interno della stessa piattaforma, dall'accettazione fino all'esecuzione del codice PHP. Ciò non riduce automaticamente il rischio operativo, ma modifica i confini delle responsabilità.

Unit non è quindi „NGINX con PHP-FPM integrato“. Durante la compilazione del modulo PHP viene creato un modulo SAPI dedicato, collegato alla libreria PHP-Embed. Durante l’analisi e la migrazione, i team devono quindi non solo trasferire le impostazioni FastCGI, ma anche riassegnare il routing, le definizioni delle applicazioni, il collegamento dei moduli e i percorsi di diagnostica. Gli errori non possono essere attribuiti in modo generico a un server web a monte o a un pool FPM separato.

Moduli PHP, versioni e limiti di configurazione

Per PHP, un’installazione di Unit richiede, oltre al kernel, un modulo di linguaggio adeguato. Questo modulo è legato alla versione di PHP utilizzata e all’installazione di Unit. Se non erano disponibili pacchetti adatti al sistema operativo e alla versione di PHP, la documentazione descriveva la procedura per la compilazione autonoma utilizzando un'installazione di PHP che fornisse la SAPI Embed. Ciò aumenta notevolmente il carico di lavoro per gli aggiornamenti, le build riproducibili e l'analisi degli errori.

Anche la configurazione segue modelli diversi. Unit raggruppa listener, route e applicazioni sotto forma di dati JSON tramite la propria interfaccia di configurazione. PHP-FPM, invece, gestisce i pool in file in formato php.ini. Questa differenza va oltre la semplice sintassi: in uno stack FPM, le regole del server web e le definizioni dei pool PHP sono separate, mentre Unit integra più strettamente entrambe in un’unica piattaforma. I piani di migrazione devono tenere conto di questa struttura.

Per le direttive PHP, Unit distingue le seguenti aree admin e utente. Le opzioni di amministrazione corrispondono a PHP_INI_SYSTEM e non possono essere modificate dall’applicazione durante l’esecuzione; le opzioni utente corrispondono a PHP_INI_USER. Unit non estende tuttavia l’intervallo consentito di una direttiva PHP. La possibilità di impostare o modificare un’opzione in questo modo o tramite il codice dell’applicazione dipende comunque dalla modalità di configurazione PHP.

Avviso: la compatibilità con PHP 8.5 indicata in Unit 1.35.0 attesta solo il supporto di questa versione nell'ultima release stabile. Non costituisce una garanzia di future correzioni di sicurezza o adeguamenti del modulo PHP di Unit. Per il funzionamento dell’ambiente di produzione, è quindi necessario documentare la data esatta di rilascio di Unit, la versione di PHP, la provenienza del modulo e un percorso di migrazione testato come dipendenza correlata.

Configurazione del routing PHP e del Front Controller

Una configurazione di unità collega un listener a delle rotte e a un’applicazione. Per una demo locale, il listener può collegarsi esclusivamente a 127.0.0.1:8080 ascoltare. Un percorso cerca innanzitutto il file richiesto in /srv/example-app/public da fornire in modalità statica. I file PHP sono esclusi da questa distribuzione tramite l'esclusione del tipo MIME e vengono inoltrati all'applicazione PHP; lo stesso vale per i file inesistenti. In questo modo, i file pubblici e l'esecuzione dell'applicazione rimangono tracciabili come fasi separate.

Nell'applicazione si imposta root definisce la directory dei documenti, mentre type: php seleziona il runtime PHP. Con script: index.php ogni richiesta inoltrata all'applicazione viene indirizzata a questo script. Ciò corrisponde al Controller frontale di molti framework PHP: l'applicazione analizza autonomamente il percorso originale e decide, ad esempio, a quale controller o pagina di errore indirizzare la richiesta.

Senza l'impostazione script Elabora percorsi di script basati su URI. Ciò può essere adatto per applicazioni meno recenti, i cui file PHP devono essere richiamati direttamente, ma richiede un'attenta limitazione dei percorsi raggiungibili. targets Consentono inoltre di definire sottosezioni con comportamenti diversi per quanto riguarda root, script o index. Non sostituiscono quindi il routing, ma rappresentano una possibilità per definire in modo mirato più regole di applicazione.

L'esempio seguente è un file di configurazione JSON per una demo locale, non per un servizio pubblico. Non contiene né nomi di dominio né dati TLS o di accesso. Prima di applicarlo, è necessario verificare i permessi del file, il supporto PHP effettivamente installato e il metodo previsto da Unit per l'importazione della configurazione.

{
  "listeners": {
    "127.0.0.1:8080": {
      "pass": "routes/example"
    }
  },
  "routes": {
    "example": [
      {
        "action": {
          "share": "/srv/example-app/public$uri",
          "types": ["!application/x-httpd-php"],
          "fallback": {
            "pass": "applications/example-php"
          }
        }
      }
    ]
  },
  "applications": {
    "example-php": {
      "type": "php",
      "root": "/srv/example-app/public",
      "script": "index.php"
    }
  }
}

L'ordine è fondamentale: il consegna statica La fase di condivisione viene tentata prima del fallback, ma esclude espressamente i file PHP. Queste richieste e i file inesistenti finiscono in index.php; in questo modo funzionano anche gli URL descrittivi come /artikel/beispiel senza un file con lo stesso nome. La necessità di regole aggiuntive per le directory di upload, le aree di amministrazione o i file PHP accessibili direttamente dipende dalla specifica applicazione e non dovrebbe essere dedotta in modo generico da questa demo.

Confrontare i modelli di processo e il budget RAM

PHP-FPM gestisce i worker per ogni pool tramite le modalità static, dynamic e ondemand. In Unit, invece, il numero di processi viene modellato all’interno dell’applicazione. Una configurazione dinamica di Unit limita con processes.max il numero totale e tiene il passo con processes.spare Processi inattivi; idle_timeout elimina i processi inattivi in eccesso.

I termini non sono quindi intercambiabili in modo univoco. In particolare, un’impostazione predefinita documentata non è un valore adeguato per un sito web. Sia pm.max_children così come processes.max limitano l’esecuzione parallela di PHP e, se i valori sono troppo bassi, possono generare code. Valori troppo elevati, invece, entrano in competizione con il sistema operativo, il database, la cache e altri servizi per l’accesso alla memoria di lavoro.

A Budget RAM Si tratta, in un primo momento, solo di un modello di pianificazione: dalla memoria totale vengono sottratte le riserve destinate al sistema operativo, al database, alla cache e ad altri processi. Il valore rimanente viene diviso per un fabbisogno di memoria stimato in modo prudente per ciascun worker PHP. Ad esempio, 1.200 MiB per PHP divisi per 120 MiB per worker danno, in teoria, dieci worker; entrambi i valori sono placeholder scelti di proposito, non rappresentano una misurazione né una raccomandazione di configurazione.

Il risultato è un Limite superiore e un punto di partenza per l'osservazione, non l'impostazione corretta. Sono determinanti i valori di picco effettivi, le code di attesa, gli errori di risposta e il fabbisogno di memoria sia in condizioni di carico tipico che elevato. Per la derivazione metodologica e la ricalibrazione di pm.max_children è utile il contributo interno Calcolare correttamente i processi figlio di PHP-FPM. In Unit vale lo stesso principio, anche se i parametri hanno nomi diversi.

Avvertenza: fissare i limiti di processo limitandosi a riprendere valori esterni spesso non fa altro che rimandare i problemi. Solo un budget di memoria ben definito e un monitoraggio costante consentono di verificare se un limite massimo per i worker è adeguato all’applicazione, alle sue estensioni e ai servizi in esecuzione simultanea.

Valutare i modelli operativi per l'hosting PHP

La tabella classifica le architetture, non la velocità o il consumo di memoria. A favore del nuovo hosting PHP con l’architettura NGINX-PHP-FPM gioca soprattutto la chiara separazione dei ruoli: il server web gestisce l’HTTP, il proxy e i contenuti statici, mentre PHP-FPM amministra i worker PHP per ogni pool. Questa suddivisione delle responsabilità facilita la valutazione separata di configurazioni, errori e aggiornamenti.

Unit è riuscita a riunire listener, routing, file statici e applicazioni in un’unica piattaforma, supportando, oltre a PHP, anche altri runtime. Questo approccio multilinguistico può spiegare perché un ambiente esistente abbia scelto Unit. Per le soluzioni basate esclusivamente su PHP, tuttavia, non rappresenta un vantaggio automatico: non sostituisce né la valutazione delle funzionalità necessarie né la verifica della capacità del team di padroneggiare a lungo termine la diversa logica di configurazione e funzionamento.

Per l'unità 1.35.0, le funzionalità tecniche devono essere definite dal Stato della manutenzione vanno distinti. La data di rilascio indica la versione pubblicata e le relative modifiche; da ciò non deriva alcun ulteriore aggiornamento del progetto, che nel frattempo è stato archiviato. Per una nuova decisione, questo limite ha un peso maggiore rispetto a un numero inferiore di componenti visibili. Per un'installazione esistente, invece, è motivo per documentare le dipendenze e un percorso di migrazione.

Apache con PHP-FPM non è un’alternativa migliore o peggiore in assoluto, ma rappresenta un’opzione in presenza di requisiti specifici per Apache. La scelta dovrebbe basarsi sulla facilità di manutenzione, sulle versioni PHP disponibili, sui processi di applicazione delle patch, sulle competenze del team e sul piano di emergenza. Senza profili di carico comparabili e una metodologia di misurazione documentata, non è possibile ricavare da questa panoramica architettonica una classifica affidabile delle prestazioni.

Gestire in modo sicuro l'unità nel parco macchine

Un'installazione esistente di Unit dovrebbe essere innanzitutto registrata come sistema esistente, non come modello per una nuova piattaforma. Sono determinanti la versione effettivamente in uso, le applicazioni collegate e le loro dipendenze. Il fatto che Unit sia ancora tecnicamente eseguibile non cambia il fatto che il progetto sia stato archiviato; la gestione operativa e la sostituzione devono quindi essere pianificate congiuntamente.

Su WordPress, Joomla o Drupal, il Controller frontale Il punto fondamentale: i percorsi che non corrispondono a file esistenti devono essere reindirizzati al file di avvio centrale di PHP, mentre i file esistenti possono essere restituiti direttamente. La guida di WordPress per Unit illustra questo principio di routing, compresa la gestione dei file PHP e /wp-admin/. Per un CMS già esistente, questa può essere una configurazione plausibile; per una nuova installazione, ciò non comporta alcuna raccomandazione per Unit.

Unit ha permesso di raggruppare diverse piccole applicazioni scritte in PHP, Python, Ruby o Node.js, con listener, percorsi e runtime, in un’unica piattaforma. Questo può spiegare perché, all’epoca, un’architettura esistente abbia optato per Unit. Nel caso di un hosting esclusivamente PHP, tuttavia, questa multilingua non è fine a se stessa: componenti separati e ben curati possono risultare più facili da mantenere nel lungo periodo, nonostante le interfacce aggiuntive.

Un deployment di container congelato richiede un inventario particolarmente accurato. A tal fine, documenta l’esatto tag dell’unità, la versione di PHP, il modulo di lingua installato, l’immagine di base e la configurazione completa. Inserisci inoltre le fonti delle immagini e dei pacchetti, il processo di applicazione delle patch, nonché un percorso di migrazione e di ripiego già testato. La compatibilità PHP di una determinata versione di Unit non garantisce che il modulo corrispondente riceva in futuro correzioni di sicurezza.

NGINX può essere posizionato a monte di Unit, ad esempio quando si desidera mantenere un livello NGINX esistente o indirizzare in modo mirato gli accessi a monte. La documentazione di Unit menziona questa integrazione anche in relazione alla protezione del Control Socket. Tuttavia, essa non risolve il problema dello stato archiviato e crea un ulteriore servizio con configurazione, registrazione e gestione degli aggiornamenti propri. È quindi necessario valutare concretamente i vantaggi rispetto a questo onere operativo.

Timeout, log e processi bloccati

I limiti di processo non costituiscono una diagnosi di errore. Con limits.requests Unit può sostituire un processo dell'applicazione dopo un numero prestabilito di richieste elaborate. Ciò consente di limitare nel tempo l'utilizzo cumulativo della memoria, ma non elimina né le perdite di memoria né le strutture di dati di dimensioni eccessive né le chiamate esterne che causano blocchi. Un riavvio regolare non deve quindi essere considerato una prova della stabilità del codice dell’applicazione.

Con limits.timeout Allo scadere del tempo configurato, Unit interrompe una richiesta con un codice HTTP 503. Si tratta di un limite di protezione visibile per le singole richieste, ma non di una protezione completa contro i worker bloccati: secondo la documentazione, Unit non rileva i processi bloccati, che possono quindi rimanere nel pool di processi. Un timeout più lungo non fa che rimandare il problema, mentre uno più breve può interrompere operazioni che normalmente sono lente.

• Registrare lo stato HTTP, i percorsi interessati, le fasce orarie e la frequenza prima di modificare i valori limite.
• Unire i log di accesso, di errore e di applicazione in base ai timestamp; nel caso di PHP-FPM, uno slowlog può fornire ulteriori indicazioni sullo stack.
• Verificare la CPU, la memoria di lavoro, le operazioni di I/O, le connessioni di rete, nonché lo stato e il numero dei processi.
• Successivamente, verificare se il codice, le query al database, gli accessi al file system e i servizi esterni possano essere la causa del problema.
• Solo una volta individuate la causa e il profilo di carico, è possibile adeguare in modo mirato i timeout, i limiti di processo o le regole di riavvio.

Un codice di errore HTTP 503 può quindi indicare il superamento del limite di tempo, ma può anche essere causato da componenti a monte o da altri errori. Non dovresti gestire le richieste PHP lunghe e ricorrenti solo regolando il numero di worker. La guida su Slowlog di PHP-FPM e analisi delle cause delle richieste lente mostra come sia possibile collegare le tracce dello stack ai dati della richiesta; la stessa logica di causa-effetto è utile anche nell'analisi dello stato delle unità.

I sintomi senza una conclusione chiara sono particolarmente critici: tempi di attesa crescenti, processi costantemente occupati o assenza di aggiornamenti nel log. In questi casi, lo stato del processo e le dipendenze sono più importanti di un aumento generico del timeout. Verifica, ad esempio, se un worker PHP è in attesa di operazioni di I/O relative al database, al DNS, al file system o alla rete. Solo l’individuazione del blocco specifico determina se sia opportuno un intervento sul codice, un adeguamento delle risorse o un riavvio controllato.

Scelta tra sistemi nuovi e vecchi

Per i nuovi ambienti di hosting PHP, un server web ben gestito con PHP-FPM rappresenta la scelta standard più logica. PHP-FPM fa parte della distribuzione standard di PHP e offre opzioni documentate relative al pool e al gestore dei processi. Nel caso di Unit, invece, la questione si sposta dalla mera funzionalità alla manutenibilità: l’installazione può continuare a funzionare, ma lo stato archiviato del progetto aumenta il rischio di una dipendenza a lungo termine.

Per i sistemi unit esistenti, una decisione obiettiva inizia con un inventario. Verifica lo stato di manutenzione e la possibilità di applicare patch al sistema operativo, a PHP e all’immagine di base, la compatibilità del modulo linguistico installato, le conoscenze operative disponibili e i servizi collegati. Altrettanto importanti sono le configurazioni esportabili, un rollback riproducibile e un sistema di destinazione su cui sia possibile trasferire gradualmente il routing, le impostazioni PHP e le distribuzioni.

Una migrazione non richiede una scadenza generica inventata di sana pianta, ma un ordine di priorità. Le applicazioni esposte a Internet, le immagini non aggiornabili, le origini dei moduli poco chiare e le applicazioni critiche per l’azienda prive di un piano di ripiego meritano la massima attenzione. Successivamente, le applicazioni possono essere raggruppate in base alla complessità e alle dipendenze. Il funzionamento in parallelo durante una transizione controllata può ridurre i rischi, a condizione che la gestione dei dati, le sessioni e il percorso di ritorno siano definiti in anticipo.

Il sito API di controllo Si tratta di un accesso amministrativo e non di un normale endpoint di un sito web. Unit lo documenta come un socket di dominio Unix e ne giustifica l’utilizzo con motivi di sicurezza. Imposta permessi sui file restrittivi e accessi amministrativi chiaramente delimitati; un’accessibilità pubblica offrirebbe agli aggressori, in caso di accesso riuscito, ampie possibilità di modificare la configurazione.

Il percorso pratico di migrazione non si esaurisce con una nuova configurazione dei processi. Trasferisci, applicazione per applicazione, la versione PHP, le estensioni, le variabili d’ambiente, i permessi dei file, le regole di routing e l’osservabilità nel sistema di destinazione. A tal fine, confronta le risposte attese e i casi di errore, anziché trarre conclusioni generiche sulla velocità. In questo modo, un retaggio non pianificato si trasforma in un processo documentato Strategia di sostituzione con scelte tecniche giustificabili.