Apache: cos’è, come funziona e a cosa serve il web server

Apache HTTP Server è un web server open source sviluppato dalla Apache Software Foundation. Il suo compito principale è ricevere richieste HTTP o HTTPS da browser e altri client, individuare la risorsa richiesta e restituire una risposta. Può servire direttamente file statici oppure collaborare con altri componenti, per esempio PHP-FPM, per generare contenuti dinamici.

Se utilizzi WordPress, potresti incontrare Apache anche senza averlo installato personalmente: molti ambienti hosting lo utilizzano come livello che riceve le richieste prima che PHP e WordPress elaborino la pagina.

C’è però una distinzione importante: Apache non è il server fisico, non è un sistema operativo e non è un browser. È un software che può essere eseguito su un server Linux, Windows o un altro sistema supportato.

In questa guida vediamo come funziona realmente Apache, cosa significano nomi come httpd e Apache2, come gestisce richieste e configurazioni, perché .htaccess è così diffuso negli hosting WordPress e in quali casi oggi ha ancora senso utilizzarlo.

Cos’è Apache HTTP Server

Apache HTTP Server, spesso chiamato semplicemente Apache o httpd, è un software che implementa le funzioni di un server HTTP.

Quando un browser richiede una pagina, un’immagine, un foglio CSS o un’altra risorsa, Apache può ricevere la richiesta sulla porta configurata, applicare le proprie regole, identificare il sito corretto e restituire la risposta.

Se vuoi prima chiarire la distinzione tra hardware, software e protocolli, trovi il modello completo nella guida su cos’è un web server.

Apache è modulare. Questo significa che molte funzioni non devono essere necessariamente incorporate nello stesso modo in ogni installazione: possono essere abilitate o disabilitate attraverso moduli e configurazione. Fra gli esempi troviamo TLS, riscrittura degli URL, reverse proxy, FastCGI e supporto HTTP/2.

Questa flessibilità è uno dei motivi per cui due server che utilizzano entrambi Apache possono comportarsi in modo molto diverso. Dire semplicemente “il sito gira su Apache” non descrive ancora la configurazione completa.

Apache è un software, non il server fisico

Nel linguaggio comune la parola server può indicare sia una macchina sia il software che fornisce un servizio. È da qui che nasce parte della confusione.

Immagina un VPS con Linux. La macchina virtuale è il server dal punto di vista dell’infrastruttura. Su quella macchina possono funzionare contemporaneamente Apache, un database, PHP-FPM, un server SSH e altri servizi.

Apache è quindi uno dei componenti software dell’infrastruttura, non l’intera infrastruttura.

Lo stesso Apache può inoltre ospitare più siti sulla stessa macchina. Attraverso i Virtual Host può distinguere le richieste in base, per esempio, al dominio richiesto e applicare configurazioni differenti a ciascun sito.

Apache, httpd e Apache2: cosa indicano questi nomi

Apache, Apache HTTP Server, httpd e apache2 vengono spesso usati come se fossero prodotti diversi. Nella maggior parte dei casi indicano invece lo stesso progetto o la sua installazione, vista da contesti differenti.

Apache HTTP Server è il nome del progetto.

httpd, abbreviazione di HTTP daemon, è il nome utilizzato dal progetto e anche dal pacchetto o servizio in diverse distribuzioni. Nei sistemi della famiglia Red Hat, per esempio, troverai normalmente il pacchetto e il servizio httpd.

Su Debian e Ubuntu incontrerai invece molto spesso il nome apache2 per pacchetto, servizio e directory di configurazione.

Questo spiega perché due tutorial possono mostrarti:

sudo systemctl restart httpd

oppure:

sudo systemctl restart apache2

senza necessariamente parlare di due web server differenti.

Apache2 non è quindi un’alternativa ad Apache: è un nome comunemente utilizzato per il ramo moderno e per il relativo packaging in alcune distribuzioni.

Apache HTTP Server e Apache Tomcat non sono la stessa cosa

Un’altra confusione frequente riguarda Apache Tomcat.

Apache HTTP Server è un server HTTP general purpose. Può servire file, terminare connessioni TLS, applicare regole, funzionare come reverse proxy e inoltrare richieste a backend applicativi.

Tomcat è invece orientato alle applicazioni Java basate sulle specifiche Jakarta, come Servlet e Jakarta Server Pages.

I due software possono anche essere utilizzati insieme. Apache HTTP Server può stare davanti a un’applicazione eseguita da Tomcat, ma Tomcat non è una nuova versione di Apache HTTP Server.

Come funziona Apache quando apri una pagina web

Per capire Apache conviene seguire una richiesta reale.

Supponiamo che tu apra:

https://www.example.com/prodotti

Prima che Apache intervenga, il browser deve individuare il server associato al dominio e stabilire la connessione necessaria. Una volta arrivata al web server, la richiesta contiene informazioni come host, percorso, metodo HTTP e header.

Apache deve quindi stabilire quale configurazione applicare e come produrre la risposta.

Il percorso essenziale può essere rappresentato così:

browser → rete → Apache → risorsa o backend applicativo → Apache → browser

La parte centrale cambia in base alla risorsa richiesta.

Dalla richiesta del browser alla risposta HTTP

Se viene richiesto un file statico e la configurazione permette ad Apache di servirlo direttamente, il flusso è relativamente semplice.

Per esempio:

browser → Apache → immagine.jpg → browser

Apache individua il Virtual Host, verifica il percorso e le regole applicabili, legge la risorsa e costruisce la risposta HTTP.

Una pagina dinamica richiede invece un passaggio ulteriore. Apache può inoltrare la richiesta al componente che esegue l’applicazione e ricevere successivamente il risultato da restituire al client.

Questa distinzione aiuta anche a capire perché web server e applicazione non vanno trattati come la stessa cosa. Apache può consegnare la risposta, ma la logica che genera quella risposta può essere eseguita altrove.

Contenuti statici, PHP-FPM e WordPress

Un esempio utile è WordPress.

Storicamente Apache e PHP sono stati spesso associati a mod_php, cioè PHP caricato direttamente come modulo del server. Non è però l’unico modello possibile e non è corretto descriverlo come l’architettura universale di Apache.

Una configurazione moderna può utilizzare PHP-FPM tramite FastCGI. Apache mette a disposizione mod_proxy_fcgi proprio per comunicare con applicazioni FastCGI, compreso PHP-FPM, come mostra la documentazione ufficiale di mod_proxy_fcgi.

In uno stack WordPress di questo tipo il percorso può diventare:

browser → Apache → PHP-FPM → WordPress → database

e poi tornare:

database/WordPress → PHP-FPM → Apache → browser

Apache riceve quindi la richiesta, ma è PHP a eseguire il codice di WordPress.

Questa distinzione è importante anche quando analizzi le performance. Se una pagina è lenta perché un plugin genera query pesanti, PHP dispone di pochi worker oppure il database risponde lentamente, cambiare web server potrebbe non risolvere il problema.

La performance di WordPress è una catena, non la caratteristica di un singolo software.

Come è fatta l’architettura di Apache

Apache è stato progettato come un sistema modulare. Il nucleo del server gestisce le funzioni fondamentali, mentre numerose capacità possono essere aggiunte attraverso moduli.

Alcuni esempi conosciuti sono:

• mod_ssl per TLS;
• mod_rewrite per la riscrittura degli URL;
• mod_proxy e moduli correlati per funzioni proxy;
• mod_proxy_fcgi per backend FastCGI;
• mod_http2 per HTTP/2;
• mod_deflate per la compressione supportata dal modulo.

Questo non significa che tutti i moduli debbano essere attivati. Una configurazione corretta dipende dalle funzioni che il server deve realmente svolgere.

Moduli e Virtual Host

I Virtual Host permettono a una singola installazione Apache di gestire più siti o applicazioni.

Il concetto è semplice. Arriva una richiesta per example.com; Apache confronta host, porta e configurazione disponibile e seleziona il Virtual Host corrispondente.

Una configurazione minimale può avere una forma simile:

<VirtualHost *:80>
    ServerName example.com
    DocumentRoot /var/www/example
</VirtualHost>

Un secondo dominio può utilizzare un altro Virtual Host e un’altra DocumentRoot, pur passando dalla stessa istanza Apache.

Nella pratica i Virtual Host possono includere molte altre direttive: certificati, log, redirect, proxy, restrizioni di accesso, impostazioni per directory e configurazioni specifiche dell’applicazione.

La modularità e la separazione per host rendono Apache adattabile a scenari molto differenti, ma hanno anche una conseguenza: per capire il comportamento di un server bisogna guardare la sua configurazione reale, non limitarsi al nome del software.

MPM event, worker e prefork: come gestiscono le connessioni

Qui conviene correggere una semplificazione molto diffusa.

Apache non può essere descritto semplicemente come “un server che crea un processo per ogni richiesta”. Il modo in cui accetta e gestisce le connessioni dipende dal Multi-Processing Module, o MPM, utilizzato.

La documentazione ufficiale Apache sugli MPM distingue, fra gli altri:

• event, basato su processi e thread e progettato per gestire in modo efficiente anche connessioni persistenti;
• worker, anch’esso multithread;
• prefork, basato su processi e utile soprattutto quando sono necessarie determinate condizioni di compatibilità con software meno adatto a un ambiente threaded.

Su Windows viene utilizzato un MPM specifico, mpm_winnt.

Apache carica un solo MPM alla volta. Sui moderni sistemi Unix-like che supportano thread e primitive di polling thread-safe, la documentazione Apache indica event come scelta predefinita nella maggior parte dei casi.

È una differenza sostanziale rispetto alla vecchia contrapposizione “Apache = un processo per richiesta, NGINX = eventi”. Quella formula può essere utile per raccontare parte della storia dei due software, ma non descrive correttamente tutte le configurazioni moderne.

File di configurazione di Apache e .htaccess

Non esiste un unico percorso universale per la configurazione Apache.

Il progetto fornisce le direttive e la struttura del software, mentre distribuzioni e pacchetti possono organizzare i file in modo differente.

Per questo copiare un comando da una guida destinata a un’altra distribuzione è uno dei modi più semplici per modificare il file sbagliato o cercare una directory che sul tuo server non esiste.

httpd.conf, apache2.conf e configurazione centrale

Su sistemi Debian e Ubuntu la configurazione è normalmente organizzata sotto:

/etc/apache2/

con il file principale:

/etc/apache2/apache2.conf

e directory come:

sites-available/
sites-enabled/
mods-available/
mods-enabled/

Su sistemi della famiglia Red Hat incontrerai invece normalmente:

/etc/httpd/

con il file:

/etc/httpd/conf/httpd.conf

e directory aggiuntive come conf.d e conf.modules.d.

Quindi httpd.conf non è il nome universale del file principale di Apache.

Prima di riavviare il servizio dopo una modifica importante conviene inoltre validare la sintassi della configurazione, per esempio con:

apachectl configtest

I comandi e i percorsi devono comunque essere verificati sulla distribuzione e sul pacchetto effettivamente installati.

Quando .htaccess è utile e quando è meglio evitarlo

I file .htaccess consentono di applicare configurazioni a livello di directory senza modificare direttamente la configurazione principale del server.

È una caratteristica particolarmente importante nell’ecosistema degli hosting condivisi e gestiti, dove l’utente può non disporre dei privilegi necessari per modificare Apache a livello globale.

WordPress ne è un esempio noto: negli ambienti Apache può utilizzare regole .htaccess, tra le altre cose, per la gestione delle riscritture degli URL.

Ma .htaccess non è automaticamente il modo migliore per configurare un server.

La stessa documentazione Apache su .htaccess raccomanda di utilizzare la configurazione principale quando si dispone dell’accesso necessario. Il motivo riguarda soprattutto performance, controllo e sicurezza: la configurazione centrale viene letta all’avvio, mentre consentire .htaccess richiede ad Apache di verificare configurazioni distribuite durante l’elaborazione delle richieste.

Il comportamento dipende inoltre da direttive come AllowOverride. Se gli override non sono consentiti, inserire una direttiva in .htaccess non la rende automaticamente attiva.

Per approfondire regole, redirect e casi WordPress trovi la guida dedicata al file .htaccess.

La regola pratica è quindi:

se amministri direttamente il server, preferisci normalmente la configurazione centrale; se operi in un hosting che delega configurazioni a livello di directory, .htaccess può essere esattamente lo strumento previsto dall’ambiente.

Installare Apache su Linux, Windows e macOS

Apache può essere eseguito su più sistemi operativi, ma installazione, nomi dei pacchetti e gestione del servizio cambiano.

Soprattutto su Linux c’è un’altra distinzione da tenere presente: la versione fornita dalla distribuzione non deve necessariamente coincidere con l’ultima release upstream pubblicata dal progetto Apache. Le distribuzioni seguono i propri cicli di manutenzione e possono applicare patch senza allineare immediatamente il numero di versione all’ultima release del progetto.

Linux: apache2 su Debian/Ubuntu e httpd su RHEL

Su Ubuntu e Debian l’installazione tipica avviene tramite il package manager:

sudo apt update
sudo apt install apache2

La documentazione Ubuntu per Apache utilizza proprio il pacchetto apache2.

Sulle distribuzioni della famiglia Red Hat il pacchetto prende normalmente il nome httpd:

sudo dnf install httpd

Dopo l’installazione, gestione del servizio, firewall, Virtual Host e policy di sicurezza vanno configurati in base al sistema operativo.

Non conviene quindi prendere una guida “Apache Linux” e applicarla indistintamente a qualsiasi distribuzione.

Se Apache deve essere installato su una macchina Ubuntu che amministri direttamente, il web server è soltanto uno strato della configurazione. Prima conviene avere una base correttamente aggiornata, raggiungibile via SSH e protetta dal firewall: nella guida alla configurazione di Ubuntu Server trovi questi passaggi e il contesto necessario per preparare il sistema prima di esporre Apache sulla rete.

Windows e macOS: cosa cambia

Su Windows c’è una particolarità importante: Apache Software Foundation distribuisce ufficialmente il codice sorgente di Apache HTTP Server, ma non i normali installer binari per Windows.

La documentazione Apache per Windows rimanda infatti a distribuzioni binarie fornite da terze parti.

Questo non significa che Apache non funzioni su Windows. Significa che bisogna distinguere il progetto ufficiale Apache dal soggetto che compila e distribuisce il pacchetto binario che stai installando.

Su macOS puoi invece ricorrere a package manager come Homebrew:

brew install httpd

Anche in questo caso percorsi e gestione del servizio dipenderanno dal metodo di installazione utilizzato.

Apache in locale: quando servono XAMPP o MAMP

Per sviluppare un sito non è sempre necessario costruire manualmente l’intero stack.

Soluzioni come XAMPP o MAMP combinano più componenti in un ambiente pensato per lo sviluppo locale e possono rendere più semplice avviare WordPress sul proprio computer.

Sono però ambienti di sviluppo, non modelli da copiare automaticamente in produzione.

Una configurazione locale privilegia spesso praticità e rapidità. Un server pubblico richiede invece decisioni specifiche su aggiornamenti, TLS, privilegi, rete, backup, logging, caching e hardening.

Sicurezza e prestazioni di Apache

Apache non diventa sicuro o veloce grazie a una singola direttiva.

Entrambi gli aspetti dipendono dalla combinazione fra versione, moduli, configurazione, sistema operativo, applicazioni servite, capacità hardware e traffico reale.

Per questo diffiderei da una lista di “valori Apache ottimali” da copiare in httpd.conf senza sapere quanta memoria ha il server, quale MPM utilizza o quale carico deve sostenere.

Aggiornamenti, TLS, moduli e superficie di attacco

Il primo controllo di sicurezza è molto meno spettacolare di molte guide di hardening: mantenere il software supportato e aggiornato.

Apache pubblica le vulnerabilità e le correzioni della serie 2.4 nella propria pagina ufficiale di sicurezza.

Oltre agli aggiornamenti, le decisioni importanti includono:

• abilitare soltanto i moduli realmente necessari;
• configurare correttamente HTTPS e i certificati;
• limitare privilegi e accessi;
• proteggere file e directory sensibili;
• controllare log ed errori;
• separare, quando possibile, i diversi livelli dell’applicazione;
• applicare firewall, WAF o altri controlli solo dove rispondono a una minaccia reale.

Apache può essere una parte della strategia di sicurezza, ma non sostituisce la sicurezza dell’applicazione.

Un WordPress vulnerabile attraverso un plugin non diventa sicuro soltanto perché il web server è ben configurato.

MPM, KeepAlive, cache e PHP-FPM: perché non esiste una configurazione migliore per tutti

Le prestazioni di Apache dipendono da ciò che gli stai chiedendo di fare.

Su un sito prevalentemente statico contano molto il numero e il comportamento delle connessioni, TLS, compressione, caching e distribuzione degli asset.

Su WordPress il percorso è più lungo:

rete → Apache → cache → PHP-FPM → WordPress → plugin/tema → database → servizi esterni

Il collo di bottiglia può essere in qualsiasi punto.

Cambiare MPM, aumentare indiscriminatamente i worker o modificare KeepAlive senza misurare il comportamento reale può semplicemente spostare il problema. Per esempio, consentire più richieste contemporanee quando PHP-FPM o il database sono già saturi può aumentare la pressione invece di risolverla.

La stessa logica vale per il confronto con altri web server. Non puoi concludere che Apache sia la causa di un sito lento soltanto perché un benchmark sintetico mostra risultati migliori con un’altra configurazione.

Prima serve capire:

1. quanto tempo impiega il server a iniziare la risposta;
2. quanto lavoro viene svolto da PHP;
3. quanto incidono database, plugin e servizi esterni;
4. se la cache interviene realmente;
5. cosa succede quando aumenta la concorrenza delle richieste.

Solo dopo ha senso decidere se intervenire su Apache o su un altro livello dello stack.

Apache è ancora attuale?

Sì. Apache HTTP Server è un progetto ancora attivamente mantenuto e utilizzato, anche se non è più corretto descriverlo come il web server dominante di Internet.

Questa distinzione è importante perché “non essere più il numero uno in una statistica di utilizzo” e “essere obsoleto” sono due affermazioni completamente diverse.

La release stabile e lo stato del progetto

Alla verifica del 17 agosto 2026, l’ultima release stabile upstream è Apache HTTP Server 2.4.68, pubblicata l’8 giugno 2026.

La pagina ufficiale di download Apache identifica la 2.4.68 come release GA corrente della serie 2.4.x e la raccomanda rispetto alle release precedenti.

Questo è il dato più utile per capire lo stato del progetto: Apache 2.4 è ancora sviluppato e riceve aggiornamenti.

Attenzione però quando controlli la versione installata sul tuo server. Un pacchetto mantenuto da una distribuzione Linux può seguire una numerazione differente dall’ultima release upstream pur ricevendo patch di sicurezza dal manutentore della distribuzione. Il numero di versione va quindi interpretato nel contesto del sistema che lo distribuisce.

Quanto è diffuso oggi Apache

Le statistiche di utilizzo dipendono dal metodo di rilevazione e non vanno confuse con una quota di mercato finanziaria.

Secondo W3Techs, nella rilevazione del 17 agosto 2026 Apache viene identificato sul 22,7% dei siti per i quali il web server è noto. Nella stessa rilevazione NGINX è al 31,4% e Cloudflare Server al 29,6%.

W3Techs specifica inoltre che un sito può utilizzare più di una tecnologia server, quindi le percentuali non descrivono necessariamente un unico software esclusivo per ogni sito.

Il dato utile non è quindi “Apache ha perso e NGINX ha vinto”. Il punto è un altro: Apache conserva una presenza molto ampia, ma oggi il mercato delle infrastrutture web è più frammentato e stratificato di quanto suggerisca una classifica a singolo server.

Un sito può, per esempio, avere un servizio edge o proxy davanti e Apache come origin server dietro di esso.

Quando Apache continua ad avere senso

Apache resta una scelta sensata soprattutto quando:

• l’infrastruttura esistente è già costruita e gestita bene intorno ad Apache;
• applicazioni o hosting dipendono da .htaccess;
• serve una configurazione modulare con funzionalità mature;
• il provider utilizza Apache come parte di uno stack WordPress consolidato;
• migrare a un altro server non risolverebbe un problema misurato.

Questo ultimo punto conta più della popolarità.

Se un sito funziona correttamente, è mantenuto, sicuro e rispetta gli obiettivi di performance, non esiste una ragione tecnica automatica per sostituire Apache perché un altro web server è più diffuso o più discusso.

Apache vs NGINX, LiteSpeed, Caddy e IIS: le differenze che contano

Chiedere quale sia “il miglior web server” senza specificare lo scenario produce quasi sempre una risposta troppo generica.

Apache, NGINX, LiteSpeed, Caddy e IIS possono sovrapporsi in alcune funzioni, ma hanno ecosistemi, configurazioni e casi d’uso differenti.

Soluzione	Punto distintivo	Scenario in cui può avere senso	Aspetto da considerare
Apache HTTP Server	Modularità, Virtual Host e configurazione distribuita tramite .htaccess quando consentita	Hosting tradizionale, WordPress, infrastrutture già basate su Apache	.htaccess non è sempre preferibile alla configurazione centrale
NGINX	Architettura fortemente event-driven, configurazione centralizzata, proxy e routing	Reverse proxy, edge/origin, siti e applicazioni con routing centralizzato	Non interpreta .htaccess
LiteSpeed Web Server	Compatibilità dichiarata dal vendor con molte configurazioni Apache e prodotto commerciale	Hosting che vuole mantenere parte dell’ecosistema/configurazione Apache	Licenza e comportamento dipendono dall’edizione utilizzata
Caddy	Automazione HTTPS e configurazione orientata alla semplicità	Deployment moderni, reverse proxy e infrastrutture relativamente snelle	Ecosistema e modello operativo sono diversi da Apache
IIS	Integrazione con Windows Server e tecnologie Microsoft	Infrastrutture costruite attorno allo stack Microsoft	Legame più stretto con l’ambiente Windows

La tabella non è una classifica prestazionale. Non avrebbe senso dichiarare un vincitore senza specificare workload, configurazione, hardware, caching e applicazione.

Non esiste un web server migliore in assoluto

NGINX viene spesso scelto come reverse proxy o web server con configurazione centralizzata. Apache conserva un vantaggio operativo in ambienti che dipendono dalla sua configurazione modulare o da .htaccess. Caddy rende particolarmente semplice automatizzare diversi aspetti di HTTPS. IIS è naturale in molte infrastrutture Microsoft.

LiteSpeed merita un discorso specifico perché viene spesso proposto dagli hosting come alternativa compatibile con l’ecosistema Apache, ma le affermazioni prestazionali del vendor non vanno trasformate automaticamente in una superiorità universale.

La domanda corretta non è quindi:

“Quale web server è più veloce?”

ma:

“Quale architettura risolve meglio il mio problema, con la mia applicazione e il mio modello operativo?”

Quale soluzione ha senso nei diversi scenari

Se gestisci un sito WordPress su un hosting che utilizza Apache e tutto funziona correttamente, il fatto che esistano NGINX, LiteSpeed o Caddy non costituisce da solo una ragione per migrare.

Se stai progettando invece una nuova infrastruttura con molti backend, routing, reverse proxy e configurazione centralizzata, NGINX o Caddy possono entrare naturalmente nella valutazione.

In un ambiente Microsoft, IIS può essere la scelta più coerente con il resto dello stack.

E se la domanda riguarda specificamente WordPress, conviene separare la teoria del web server dai problemi reali dell’applicazione. Nel nostro confronto Apache vs NGINX per WordPress il punto decisivo dovrebbe essere sempre lo scenario concreto, non il nome del software.

Conclusione

Apache HTTP Server non è un residuo della prima era del Web e non è nemmeno il web server che bisogna scegliere per abitudine.

È un server HTTP maturo, modulare e ancora attivamente mantenuto, con una caratteristica particolarmente importante nell’ecosistema hosting: può combinare configurazione centrale e configurazione distribuita tramite .htaccess.

Capire come funziona cambia anche il modo in cui affronti i problemi. Apache riceve e gestisce richieste HTTP, ma su un sito WordPress la generazione della pagina può dipendere da PHP-FPM, WordPress, plugin, database, cache e servizi esterni. Attribuire al solo web server qualsiasi problema di velocità significa guardare soltanto un pezzo della catena.

Se amministri un’infrastruttura già basata su Apache e non hai un problema concreto da risolvere, non serve migrare per inseguire una classifica di popolarità. Se invece stai progettando un nuovo stack, confronta Apache con le alternative sulla base di configurazione, compatibilità, gestione operativa, proxy, applicazione e workload.

Il punto non è scegliere il server web “migliore” in astratto. È capire quale componente serve davvero all’architettura che devi gestire.