Apache vs. NGINX: qual è il miglior web server per WordPress?

Se esegui WordPress sul tuo VPS, sia Apache sia NGINX possono servire bene il sito, ma fanno compromessi diversi. NGINX di solito è la scelta predefinita migliore per alta concorrenza, distribuzione di file statici e HTTP/3 opzionale. Apache è più semplice quando il tuo stack WordPress dipende da .htaccess o da moduli specifici di Apache.

Questo confronto tra Apache e NGINX si concentra sulle differenze che contano per WordPress: architettura, gestione di PHP, configurazione, HTTP/3 e se valga la pena la complessità in più di eseguirli entrambi. LiteSpeed e Caddy restano fuori dal discorso.

Risposta breve: per un VPS WordPress autogestito, scegli NGINX come impostazione predefinita. Scegli Apache se il tuo sito o i tuoi plugin dipendono molto da .htaccess. Esegui entrambi solo quando ti serve davvero NGINX davanti senza rinunciare alla compatibilità con Apache.

Che cos'è Apache?

Apache è un software per server web open source molto diffuso, sviluppato e mantenuto dall'organizzazione statunitense senza scopo di lucro Apache Software Foundation (ASF). È noto anche come Apache HTTP Server e HTTPD.

La pagina di download di Apache indica la 2.4.68, rilasciata a giugno 2026, come versione stabile attuale.

Apache HTTP Server è un server open source modulare con un supporto maturo per le regole .htaccess per directory, diversi moduli multi-processo (MPM), reverse proxy, riscrittura degli URL, TLS e moduli caricati dinamicamente. Per WordPress il suo vantaggio pratico maggiore è la compatibilità di configurazione, non la velocità pura.

Le funzionalità di Apache che contano di più in questo confronto sono i suoi MPM prefork, worker ed event; .htaccess; HTTP/2; reverse proxy e bilanciamento del carico; supporto FastCGI; moduli dinamici; riscrittura degli URL; e TLS.

Che cos'è NGINX?

NGINX («engine x») è un server web open source, reverse proxy, cache dei contenuti, bilanciatore di carico, proxy TCP/UDP e proxy di posta, scritto originariamente da Igor Sysoev. I suoi processi worker usano un modello a eventi pensato per gestire molte connessioni simultanee con un costo ridotto per connessione.

La pagina di download di NGINX lists the 1.30.x stable branch and the 1.31.x mainline branch.

Apache vs. NGINX: le differenze chiave per WordPress

Apache e NGINX si distinguono soprattutto per come gestiscono connessioni, configurazione, PHP e supporto ai protocolli. Il comportamento di Apache dipende molto dall'MPM che usa, mentre NGINX si basa su processi worker a eventi.

Apache vs. NGINX: architettura

Il modello di gestione delle richieste di Apache dipende dall'MPM che usi. Prefork si basa sui processi, mentre worker ed event usano i thread. NGINX impiega processi worker costruiti attorno a cicli di eventi. Il classico confronto «Apache orientato ai processi contro NGINX orientato agli eventi» è quindi troppo semplicistico per un'installazione Apache 2.4 attuale.

L'MPM event di Apache può passare le connessioni keep-alive inattive al suo thread listener invece di occupare un thread worker per ciascuna. NGINX tende ancora ad avere un costo per connessione più basso con numeri molto alti di connessioni simultanee, ma la distanza architetturale è molto più stretta di quanto suggeriscano i vecchi confronti dell'era prefork.

Apache vs. NGINX: prestazioni

Il vantaggio prestazionale di NGINX emerge soprattutto con alta concorrenza e carichi di file statici. I suoi worker a eventi possono tenere aperte molte connessioni con un costo per connessione relativamente basso. L'MPM event di Apache riduce parecchio quel divario rispetto alle vecchie configurazioni prefork.

Le richieste dinamiche di WordPress sono un altro discorso. NGINX di norma inoltra PHP a FastCGI, di solito PHP-FPM. Anche Apache può usare PHP-FPM tramite FastCGI, oppure eseguire PHP con un modulo Apache.

Una volta che PHP inizia a eseguire WordPress, il codice dei plugin, le query al database, la cache a oggetti o di pagina e il dimensionamento dei worker PHP possono contare più del web server davanti. Se un plugin esegue una dozzina di query pesanti per richiesta, passare da Apache a NGINX non risolverà il problema di fondo.

Apache vs. NGINX: supporto per HTTP/3 e QUIC

HTTP/3 è la versione attuale del protocollo e viaggia su QUIC anziché su TCP. Che il tuo sito possa offrirlo dipende dal web server che sta davanti, ed è l'unico punto del confronto in cui i due server non sono vicini.

NGINX include un modulo HTTP/3 dalla versione 1.25.0. Non viene compilato per impostazione predefinita e la build richiede il parametro --with-http_v3_module.

La documentazione del modulo HTTP/3 di NGINX descrive ancora il modulo come «experimental, caveat emptor applies».

Apache 2.4 non include alcun modulo nativo per HTTP/3 o QUIC; il supporto ai protocolli si ferma a mod_http2.

La conseguenza pratica per chi gestisce un sito: un'installazione standard di Apache 2.4 non offre HTTP/3. In produzione l'opzione concreta resta terminare HTTP/3 su un reverse proxy o una CDN compatibili posti davanti ad Apache. Se vuoi il protocollo, una possibilità è mettere NGINX davanti ad Apache e lasciare che sia NGINX a terminare le connessioni dei client, l'assetto descritto più avanti.

Apache vs. NGINX: sicurezza

Né Apache né NGINX è categoricamente «più sicuro». Sono entrambi progetti maturi con manutenzione di sicurezza attiva, e la sicurezza di un deployment in produzione dipende più dalle patch, dai moduli abilitati, dalla configurazione TLS, dai controlli di accesso, dai limiti di frequenza e dall'applicazione dietro al server.

Il confronto utile riguarda la superficie di attacco e la configurazione, non un vincitore assoluto. Disattiva i moduli e gli endpoint che non ti servono, tieni il server aggiornato e irrobustisci lo stack WordPress che sta dietro.

Apache vs. NGINX: configurazione

I file .htaccess per directory di Apache funzionano ogni volta che AllowOverride lo consente. È utile per WordPress, perché le regole di riscrittura si possono modificare senza toccare la configurazione globale del server.

Quella comodità ha un costo. La documentazione ufficiale di Apache consiglia di mettere le regole nella configurazione principale del server quando hai accesso root: i file .htaccess vengono controllati durante le richieste, e abilitarli introduce considerazioni sia di prestazioni sia di sicurezza.

NGINX non ha un equivalente di .htaccess. La sua configurazione è centralizzata, quindi WordPress non può scrivere per te regole di riscrittura a livello di server. Le regole dei permalink e le direttive di server richieste da un plugin le deve aggiungere un amministratore alla configurazione di NGINX, che va poi ricaricata.

Apache vs. NGINX: moduli ed estensibilità

Apache ha un supporto maturo per i Dynamic Shared Object (DSO): i moduli si possono compilare separatamente e caricare con LoadModule. Anche NGINX supporta i moduli dinamici tramite load_module, ma la compatibilità binaria con la versione di NGINX installata e con la sua configurazione di build pesa di più quando usi moduli di terze parti non standard.

Apache è quindi in vantaggio se dipendi da moduli di terze parti insoliti. Per l'hosting WordPress tipico, quella differenza conta di solito meno di .htaccess, della gestione di PHP e degli strumenti che usi già.

Apache vs. NGINX: supporto delle piattaforme

Apache gira su Linux, Windows, macOS e molti sistemi Unix-like. Anche NGINX è disponibile sulle principali piattaforme, ma la sua build nativa per Windows ha limiti importanti. NGINX continua a definire beta la versione per Windows, dice di non aspettarsi prestazioni elevate né scalabilità, precisa che un solo worker svolge davvero il lavoro e non supporta né UDP né QUIC. Per un deployment NGINX in produzione, un sistema Unix-like resta la scelta pratica.

Apache vs. NGINX: gestione delle richieste

Apache di norma mappa l'URL di una richiesta sul filesystem sotto DocumentRoot, mentre il suo sistema di configurazione può anche applicare location basate sull'URI, riscritture e regole di proxy. NGINX seleziona prima un blocco server e poi un blocco location, soprattutto in base all'URI della richiesta, prima di decidere se servire un file o passare la richiesta a monte.

Quella differenza cambia il modo in cui scrivi la configurazione, ma di per sé non dimostra che NGINX trasferisca i dati più velocemente.

Un confronto rapido tra NGINX e Apache

Ecco come si posizionano i due server sugli assi visti sopra, più il supporto ai protocolli e la versione attuale di ciascuno.

Usare Apache e NGINX insieme

Sì, puoi eseguirli entrambi. Un assetto ibrido comune mette NGINX davanti come reverse proxy verso i client e Apache dietro. NGINX può terminare TLS e HTTP/2, e può terminare HTTP/3 quando il suo modulo HTTP/3 sperimentale è compilato e attivo. Può anche servire da sé alcuni file statici, passando ad Apache le richieste applicative.

L'avvertenza importante riguarda la proprietà delle regole. Una richiesta che NGINX serve direttamente non arriva mai ad Apache, quindi le regole .htaccess di Apache non si applicano. Le due configurazioni devono concordare su riscritture, cache, inoltro dell'IP del client, comportamento TLS e su quale server governa ciascun percorso.

Il costo è che ora stai facendo girare due web server. Due configurazioni che devono andare d'accordo, due cicli di aggiornamento da seguire e un posto in più dove guardare quando una richiesta restituisce qualcosa di inatteso. Su un singolo sito piccolo quel peso di solito supera il vantaggio; inizia a ripagare quando vuoi HTTP/3 o una consegna statica più veloce senza rinunciare al comportamento .htaccess da cui dipendono i tuoi plugin.

NGINX è più semplice di Apache?

Nessuno dei due è più semplice in assoluto. NGINX lo è se preferisci una configurazione centralizzata e ti trovi a tuo agio a modificare i blocchi server. Apache lo è quando WordPress o i plugin di terze parti si aspettano regole .htaccess, perché quelle regole agiscono a livello di directory senza toccare la configurazione globale del server.

Su un server che controlli, «più semplice» si riduce soprattutto a quale modello di configurazione il tuo stack si aspetta già.

Quando scegliere Apache invece di NGINX?

Scegli Apache quando il tuo stack WordPress dipende da .htaccess, quando plugin o strumenti del pannello di controllo si aspettano direttive di riscrittura di Apache, o quando ti serve un modulo Apache specifico. È anche ragionevole tenere Apache su un sito esistente che va già bene: cambiare web server per un guadagno teorico nei benchmark raramente vale il disturbo.

Quando scegliere NGINX invece di Apache?

Scegli NGINX quando ti aspetti molte connessioni simultanee, vuoi un solido livello per i file statici o per il reverse proxy, preferisci una configurazione centralizzata, o vuoi la possibilità di attivare HTTP/3. Per WordPress il rovescio della medaglia è che le regole di riscrittura e le direttive di server richieste dai plugin diventano un compito dell'amministratore, non qualcosa che WordPress può scrivere in .htaccess.

NGINX vs Apache: il miglior web server per WordPress?

Usa NGINX. Per un sito WordPress su un server che controlli è la scelta predefinita migliore: costo per connessione contenuto in alta concorrenza, distribuzione efficiente dei file statici e HTTP/3 disponibile se lo vuoi.

L'eccezione è .htaccess, e conta. WordPress può scrivere regole di riscrittura per Apache quando .htaccess è abilitato, ma non può modificare la configurazione di NGINX. Se un plugin si aspetta direttive di riscrittura, di sicurezza o di cache, ti servono le sue istruzioni per NGINX o una regola equivalente nel blocco server, seguite da un reload di NGINX. Se non vuoi quella responsabilità operativa, Apache è la scelta WordPress più semplice. Su un sito con traffico normale, a limitare le prestazioni saranno più probabilmente PHP, il database e la cache che non il web server.

Sotto a tutto questo c'è un presupposto: il server deve essere tuo e modificabile. Su un hosting WordPress gestito, il web server lo decide il provider, e la risposta a questa domanda è semplicemente ciò che usa già. Questo confronto è per chi ha accesso root sulla propria macchina.

Come capire se stai usando Apache o NGINX?

Se è il tuo VPS, controlla direttamente i servizi in esecuzione:

systemctl status nginx
systemctl status apache2   # Debian/Ubuntu
systemctl status httpd     # RHEL/Fedora-family systems

Per un sito remoto che non controlli, l'header di risposta HTTP Server può essere un indizio, ma non è decisivo. Un reverse proxy o una CDN possono esporre il proprio software server al posto di quello dell'origine, e l'header può anche essere nascosto o modificato.

Ospitare Apache o NGINX su un VPS

Se il VPS è tuo, entrambi i server sono semplici da far girare. Dimensiona la macchina per l'intero stack WordPress, non solo per Apache o NGINX: worker PHP, database, cache, traffico e job in background di solito consumano più risorse del web server stesso.

Qualunque server tu scelga, configurazione, aggiornamenti, TLS, backup e monitoraggio sono a tuo carico. Eseguirli entrambi aggiunge una configurazione e un percorso di aggiornamento in più, quindi usa l'assetto ibrido solo se hai un motivo preciso.

Il VPS NGINX di Cloudzy è un VPS Linux autogestito con accesso root completo, quindi la configurazione del server resta tua.

L'immagine Apache HTTP Server nel nostro marketplace si installa allo stesso modo, con un clic, così mettere in piedi l'uno o l'altro, o entrambi, non inizia con una compilazione dai sorgenti.

LEGGI

Caddy vs Nginx su un VPS: il confronto tra i file di configurazione

Domande frequenti

Apache è meglio di NGINX?

Nessuno dei due è migliore in assoluto. NGINX di solito è la scelta predefinita più solida quando ti interessano alta concorrenza, distribuzione di file statici, reverse proxy o HTTP/3. Apache di solito è più semplice quando il tuo stack WordPress dipende da .htaccess o da moduli specifici di Apache.

Perché NGINX è più veloce di Apache?

NGINX può gestire molte connessioni dentro il ciclo di eventi di ciascun worker, il che mantiene basso il costo per connessione in alta concorrenza. Anche l'MPM event di Apache gestisce le connessioni in modo asincrono, quindi il divario è più piccolo di quanto suggeriscano i vecchi confronti con prefork. Su WordPress, PHP, le query al database e la cache possono contare più della differenza tra i due web server.

Per WordPress conviene Apache o NGINX?

Per un VPS WordPress autogestito, NGINX è un'ottima scelta predefinita se ti trovi a tuo agio a gestire da solo le regole nei blocchi server. Scegli Apache se ti affidi a .htaccess o a plugin che si aspettano regole di riscrittura di Apache e vuoi che funzionino con meno configurazione manuale del server.

Perché NGINX è così diffuso?

NGINX combina una gestione efficiente delle richieste in alta concorrenza con reverse proxy, bilanciamento del carico, cache, supporto FastCGI e terminazione TLS. Questo lo rende utile sia come web server principale sia come proxy frontale.

Perché Apache è ancora usato?

Apache resta molto diffuso grazie al suo ecosistema di moduli, al supporto di .htaccess, agli strumenti maturi, all'ampio supporto delle piattaforme e alla compatibilità con i flussi di lavoro di hosting e pannelli di controllo costruiti attorno a esso.

Qual è la differenza tra Apache e apache2?

Su Debian e Ubuntu, apache2 è il nome del pacchetto e del servizio di Apache HTTP Server. I sistemi della famiglia RHEL e Fedora di solito chiamano quel servizio httpd. Non sono web server diversi: entrambi indicano Apache HTTP Server. Il ramo stabile attuale di Apache è il 2.4, con la 2.4.68 come versione più recente.

Apache supporta HTTP/3?

Non in modo nativo. Apache HTTP Server 2.4 non include un modulo HTTP/3 o QUIC; il supporto ai protocolli che porta con sé si ferma a HTTP/2. Se ti serve HTTP/3 in produzione, puoi terminarlo su un reverse proxy o una CDN compatibili davanti ad Apache.