Configurazione e ottimizzazione Apache HTTP Server

Apache HTTP Server serve ancora una quota enorme delle applicazioni in produzione: modulare, stabile e documentato come pochi. Molti CMS, applicazioni PHP e software legacy danno per scontati Apache e il suo .htaccess. Noi lo configuriamo per il carico reale - non con il file di default della distribuzione - così resta veloce, sicuro e libero da vincoli.

Panoramica

Interveniamo su Apache in ogni fase della sua vita: prima installazione, messa a punto di un server esistente, diagnosi di un collo di bottiglia o migrazione verso un’architettura diversa. Il punto di partenza è sempre la configurazione che hai davvero - virtual host, moduli caricati, regole .htaccess stratificate negli anni - che riportiamo a uno stato pulito, versionato e prevedibile.

Apache paga la sua flessibilità con qualche insidia nota: mod_php che moltiplica la memoria, MPM prefork che limita la concorrenza, .htaccess riletti a ogni richiesta. Sono problemi risolvibili, quasi sempre senza cambiare web server. Quando invece Apache non è la scelta più efficiente per il tuo caso, te lo diciamo apertamente: spesso basta mettergli Nginx davanti come cache, senza buttare via nulla di ciò che funziona.

Problemi tipici che risolviamo

• Il sito rallenta nei picchi e la memoria del server si esaurisce → migriamo da mod_php a PHP-FPM con MPM event e calibriamo i limiti sui numeri reali.
• Regole .htaccess stratificate che si contraddicono → audit completo, pulizia dei duplicati e spostamento nel virtual host dove conviene.
• Redirect a catena che rallentano le pagine e sprecano crawl budget → riscriviamo le regole mod_rewrite in modo ordinato e le testiamo prima del rilascio.
• Certificato scaduto e sito marchiato come non sicuro → automatizziamo emissione e rinnovo con Let’s Encrypt e teniamo d’occhio le scadenze.
• Pagine servite senza compressione né cache → abilitiamo HTTP/2, Brotli e header di caching corretti per abbassare il TTFB.
• Configurazione ereditata che nessuno osa toccare → la ricostruiamo passo passo in staging e la documentiamo, così smette di essere una scatola nera.
• Scan e richieste anomale continui sui path sensibili → hardening con header di sicurezza, limiti sulle richieste e moduli superflui disattivati.

Cosa include

• Virtual host: più siti sullo stesso server, name-based o IP-based, con log, permessi e pool PHP separati per non farsi male a vicenda.
• mod_rewrite e .htaccess: scrittura, pulizia e ottimizzazione di redirect, rewrite e URL SEO-friendly, con test prima del rilascio.
• Da mod_php a PHP-FPM: migrazione a PHP-FPM con MPM event per ridurre la memoria e aumentare la concorrenza, senza rompere le regole esistenti.
• Caching e compressione: mod_cache, mod_expires, mod_deflate e Brotli, con header calibrati per abbattere il TTFB.
• TLS e certificati: cipher moderni, HSTS, HTTP/2 e rinnovo automatico via Let’s Encrypt.
• Hardening: header di sicurezza, blocco dei path sensibili, limiti su richieste e body, riduzione dei moduli attivi alla lista minima.
• Coesistenza o migrazione con Nginx: Apache dietro Nginx come layer di cache, oppure traduzione graduale delle regole verso Nginx.

Stack e tecnologie

Lavoriamo su Apache 2.4 con MPM event e PHP-FPM, la combinazione che oggi offre il miglior rapporto tra memoria e concorrenza. Abilitiamo solo i moduli necessari - mod_rewrite, mod_ssl, mod_headers, mod_proxy, mod_cache - e integriamo Let’s Encrypt per i certificati. Dove i numeri lo giustificano affianchiamo Nginx o Varnish come cache davanti ad Apache, e colleghiamo il tutto al monitoraggio di log e performance. Operiamo prevalentemente su Debian e Ubuntu; su richiesta anche AlmaLinux, Rocky Linux, Arch Linux e altre distribuzioni. Il server può stare dove preferisci: bare-metal, VPS o cloud - usiamo soprattutto Google Cloud, con AWS e DigitalOcean come alternative. Ogni modifica finisce in configurazioni versionate e commentate, non in ritocchi al volo che dopo sei mesi nessuno sa spiegare.

Un esempio d’intervento

Un’agenzia ci ha affidato un server ereditato con una decina di siti WordPress su Apache in prefork con mod_php: nei momenti di traffico la memoria si esauriva, il server finiva in swap e tutti i siti rallentavano insieme. Abbiamo replicato la configurazione in staging, migrato a MPM event con un pool PHP-FPM per sito, ripulito i .htaccess dai rewrite duplicati e attivato HTTP/2 con compressione Brotli. La migrazione in produzione è avvenuta in una finestra concordata, senza downtime percepito. Oggi la memoria per richiesta è una frazione di prima, un sito che riceve un picco non trascina più gli altri e l’agenzia ha una mappa scritta di virtual host e pool, sito per sito.

A chi si rivolge

• Applicazioni PHP e CMS - WordPress, Drupal, Magento - e software legacy che dipendono da .htaccess.
• Aziende e agenzie con un server Apache ereditato, poco documentato o lento sotto carico.
• Chi valuta il passaggio a PHP-FPM con MPM event, o l’introduzione di Nginx senza riscrivere tutto.
• Team che ospitano più siti sullo stesso server e vogliono virtual host puliti e isolati tra loro.

Come lavoriamo

Prima di toccare qualsiasi cosa fotografiamo lo stato attuale: moduli caricati, virtual host, regole attive e consumo reale di memoria. Su quella base proponiamo l’intervento più semplice che regge il carico, lo proviamo in staging e concordiamo con te la finestra di rilascio. Le configurazioni che ti lasciamo sono standard, aperte e documentate: nessun componente proprietario, nessun passaggio che conosciamo solo noi. Hai un referente tecnico unico e report che si leggono senza dizionario. La copertura ordinaria è lun-ven 10:00-18:00 , con priorità e tempi descritti nei tempi di risposta; per gli interventi ricorrenti molti clienti scelgono i pacchetti ore, che non scadono. Il preventivo è gratuito, con risposta in giornata lavorativa.