Nginx o Apache: quale scegliere

Devi installare un server web sulla tua macchina e ti fermi alla prima riga: apt install nginx o apt install apache2? La rete è piena di confronti che finiscono con "dipende", il che è vero ma non ti aiuta a scegliere stasera. In questo articolo trovi la differenza reale tra i due — che è architetturale, non di prestazioni pure — cosa cambia sotto carico, perché .htaccess è il vero motivo per cui Apache sopravvive, e un verdetto pratico caso per caso.

Cos'è la differenza

Nginx e Apache fanno lo stesso mestiere — ricevere richieste HTTP e rispondere — ma le gestiscono in due modi opposti: Apache assegna un processo o un thread a ogni connessione, Nginx usa pochi processi che gestiscono migliaia di connessioni a turno.

Tutto il resto del confronto discende da qui. Non è che uno sia "veloce" e l'altro "lento": sono due scommesse diverse su cosa sia scarso, la memoria o la complessità.

Le due architetture

Apache: un processo per connessione

Il modello storico di Apache è semplice da capire. Arriva una richiesta, Apache le dedica un processo (o un thread) che la segue dall'inizio alla fine, e poi lo libera.

Il vantaggio è che ogni richiesta ha il suo spazio isolato: se il codice PHP che gira dentro quel processo esplode, gli altri non se ne accorgono. È anche il motivo per cui Apache può eseguire l'interprete PHP dentro di sé, con mod_php.

Il costo è la memoria. Ogni processo occupa qualche megabyte, e mille connessioni contemporanee significano un consumo che cresce in modo lineare. Se le connessioni sono lente — utenti mobili, reti scadenti — quei processi restano occupati ad aspettare senza fare niente di utile.

Apache moderno mitiga il problema con i MPM (Multi-Processing Module). prefork è il vecchio modello a processi, worker usa i thread, event è il più efficiente e si comporta molto più come Nginx sulle connessioni in attesa. Se usi Apache oggi, usa event.

apachectl -V | grep MPM      # quale MPM è attivo
sudo a2dismod mpm_prefork
sudo a2enmod mpm_event
sudo systemctl restart apache2

Attenzione: mpm_event non è compatibile con mod_php. Devi passare a PHP-FPM, che è comunque la scelta giusta oggi.

Nginx: pochi processi, tanti eventi

Nginx avvia un numero di processi worker pari (di solito) al numero di core della CPU. Ogni worker gestisce migliaia di connessioni in un ciclo a eventi: quando una connessione è in attesa di dati, il worker non resta fermo, passa alla successiva.

Il risultato è che il consumo di memoria è quasi piatto rispetto al numero di connessioni. Diecimila connessioni aperte e per lo più inattive — la situazione tipica di un sito reale — sono un caso normale, non un problema.

Il costo è che Nginx non esegue codice applicativo al suo interno. Non esiste mod_php per Nginx: il PHP lo passa a PHP-FPM, un processo separato. Nella pratica non è un difetto, è la separazione dei ruoli che vuoi comunque.

Sotto carico, cosa succede davvero

Su una singola pagina servita a un utente alla volta, la differenza è invisibile. Il divario si apre in tre situazioni:

• Molte connessioni concorrenti. Qui Nginx vince nettamente. Apache con prefork inizia a soffrire prima, e quando la memoria finisce il sistema comincia a usare lo swap e le prestazioni crollano di colpo, non gradualmente.
• File statici. Immagini, CSS, JavaScript: Nginx li serve con meno lavoro per richiesta. La differenza si sente su siti con molte risorse, meno su un'API che restituisce JSON.
• Connessioni lente. È il caso in cui Nginx è più avanti di tutti. Un utente su rete mobile che scarica un file per trenta secondi occupa un processo Apache prefork per trenta secondi, e quasi nulla in Nginx.

Dove la differenza non conta: se il tuo collo di bottiglia è una query al database che impiega 400 ms, il server web non è il problema. Cambiare da Apache a Nginx ti farà risparmiare qualche millisecondo su quattrocento. Prima di ottimizzare qui, misura — il tema è approfondito in come velocizzare un sito web.

.htaccess: il vero motivo per cui Apache è ancora ovunque

Questa è la differenza che nella pratica pesa più dell'architettura.

Apache legge, a ogni richiesta, i file .htaccess presenti nelle directory del sito. Puoi mettere regole di riscrittura, redirect, protezioni con password e intestazioni in un file nella cartella del sito, e hanno effetto immediato senza toccare la configurazione del server e senza riavviare nulla.

# .htaccess — funziona subito, senza riavvio
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^(.*)$ index.php [QSA,L]

Questo è il motivo per cui tutto l'ecosistema PHP — WordPress in testa — dà per scontato Apache. E il motivo per cui su un hosting condiviso trovi quasi sempre Apache: permette al provider di darti il controllo sulle regole del tuo sito senza darti accesso alla configurazione del server.

Nginx non ha un equivalente, per scelta. Le regole stanno nella configurazione centrale, che va ricaricata dopo ogni modifica:

location / {
    try_files $uri $uri/ /index.php?$query_string;
}

sudo nginx -t && sudo systemctl reload nginx

I due lati della medaglia sono onesti. .htaccess è comodo e costa prestazioni: Apache deve controllare quei file a ogni richiesta, in ogni directory del percorso. Nginx è più veloce e meno flessibile: se non hai accesso root, non cambi niente.

Se stai migrando un sito da Apache a Nginx, il lavoro vero è tradurre gli .htaccess. Preventiva qualche ora e verifica i redirect uno per uno.

Moduli e configurazione

Apache ha un sistema di moduli caricabili a caldo, con un catalogo enorme accumulato in trent'anni. a2enmod e a2dismod attivano e disattivano funzionalità senza ricompilare niente. Per casi particolari — autenticazione LDAP, integrazioni legacy, moduli aziendali specifici — spesso il modulo Apache esiste e l'equivalente Nginx no.

Nginx ha un insieme di moduli più ristretto e, storicamente, i moduli di terze parti richiedevano la ricompilazione. Oggi i moduli dinamici esistono, ma la cultura resta quella di un server essenziale.

La sintassi di configurazione è questione di gusti, ma con una differenza pratica: quella di Nginx è più compatta e più difficile da sbagliare, quella di Apache è verbosa e piena di direttive che si comportano diversamente a seconda del contesto in cui le metti.

Tabella comparativa

	Nginx	Apache
Architettura	Eventi, pochi worker	Processo/thread per connessione (event mitiga)
Memoria sotto carico	Quasi piatta	Cresce col numero di connessioni
File statici	Molto efficiente	Buono, un po' più costoso
Connessioni lente	Gestite senza costo	Occupano risorse (meno con event)
.htaccess	Non esiste	Il suo punto di forza
PHP	Sempre via PHP-FPM	mod_php o PHP-FPM
Moduli	Essenziali, catalogo ristretto	Enorme, tutto caricabile a caldo
Reverse proxy	Il suo mestiere naturale	Funziona, meno idiomatico
Documentazione trovabile	Ottima	Ottima, ma piena di guide vecchie

Errori comuni che fanno perdere ore

Installarli entrambi sulla stessa macchina. Succede più spesso di quanto sembri: installi Apache, poi provi Nginx, e il secondo non parte perché la porta 80 è occupata. Il messaggio (Address already in use) non nomina il colpevole.

sudo ss -tlnp | grep ':80'    # chi occupa la porta
sudo systemctl disable --now apache2

Modificare la configurazione di Nginx e non ricaricare. Non c'è nessun avviso: continui a vedere il vecchio comportamento e cerchi l'errore nel posto sbagliato. nginx -t && systemctl reload nginx, sempre, dopo ogni modifica.

Restare su mpm_prefork con mod_php nel 2026. È la configurazione predefinita di molte guide vecchie ed è la causa numero uno dei "Apache è lento". Passa a mpm_event più PHP-FPM prima di concludere che ti serve cambiare server.

Aspettarsi che .htaccess funzioni su Nginx. Non c'è errore, il file viene semplicemente ignorato. Il sito risponde, i redirect no, e tu passi un'ora a guardare un file che nessuno sta leggendo.

Dimenticare le intestazioni X-Forwarded-* quando fai da proxy. Vale per entrambi, ed è la trappola classica: l'applicazione dietro vede tutte le richieste arrivare da 127.0.0.1. Il dettaglio è in cos'è un reverse proxy.

Il verdetto pratico

Scegli Nginx se: stai mettendo online un'applicazione Node, Python, Go o Ruby su un VPS; ti serve un reverse proxy davanti a uno o più servizi; hai molte connessioni concorrenti; stai lavorando con i container; oppure semplicemente stai partendo da zero e non hai vincoli. È la scelta predefinita ragionevole oggi, e la maggior parte delle guide recenti la dà per scontata.

Scegli Apache se: gestisci WordPress o un'applicazione PHP che si porta dietro .htaccess che nessuno ha voglia di riscrivere; hai bisogno di un modulo specifico che esiste solo per Apache; devi dare a più utenti il controllo sulle regole dei rispettivi siti senza dargli root; oppure il team lo conosce già bene. Un Apache con mpm_event e PHP-FPM configurato bene regge senza problemi la stragrande maggioranza dei siti reali.

Non cambiare server per prestazioni senza aver misurato. Se il sito è lento con Apache, nove volte su dieci il problema è il database, l'assenza di caching o le immagini da tre megabyte, non il server web.

E puoi anche usarli insieme: Nginx davanti come reverse proxy per HTTPS e file statici, Apache dietro per le applicazioni PHP con i loro .htaccess. È una configurazione classica, non un ripiego. Costa un pezzo in più da mantenere, quindi ha senso solo se hai davvero bisogno di entrambi.

In sintesi

La differenza è architetturale, non di velocità pura. Apache dedica un processo a ogni connessione, Nginx ne gestisce migliaia con pochi worker.

Nginx vince su concorrenza, memoria e connessioni lente. È la scelta naturale come reverse proxy davanti a un'applicazione moderna.

Apache vince su .htaccess e sulla varietà dei moduli. È il motivo per cui l'ecosistema PHP e l'hosting condiviso restano suoi.

Per un progetto nuovo su un tuo server, prendi Nginx e non pensarci più. Per un sito PHP esistente che funziona su Apache, lascialo dov'è e sistema semmai l'MPM.

Se stai preparando la macchina adesso, il percorso completo è in come configurare un VPS da zero. E quando un solo server non basta più, il passo successivo è il load balancing.