Installare Apache su Windows 10 con WSL: guida al server web

Se l’obiettivo è avere Apache su Windows 10 passando da WSL, la scelta giusta va chiarita subito: funziona bene per sviluppo e test locali, non è la strada che userei per esporre un sito in produzione. Il punto forte è la comodità: un ambiente Linux reale, toolchain coerente, log e configurazioni vicine a quelle di un server vero. Il limite è altrettanto chiaro: rete, avvio dei servizi, integrazione con Windows e prestazioni non coincidono con un’installazione nativa su Linux.

In pratica hai due modelli. Il primo è installare Apache dentro la distro WSL e lavorare su localhost. Il secondo è usare Apache in WSL per servire contenuti anche verso la rete locale, con tutte le cautele del caso. Qui tratto il primo caso come base, poi aggiungo le varianti utili quando devi ascoltare su una porta specifica, usare PHP, o verificare che il sito risponda dal browser di Windows.

Perché Apache in WSL ha senso solo in certi casi

Apache in WSL ha senso quando vuoi replicare un ambiente Linux senza lasciare Windows, oppure quando devi testare virtual host, rewrite, header, permessi e file di configurazione con semantica Unix. Ha meno senso se cerchi un server sempre acceso, con servizio gestito da systemd e rete stabile verso l’esterno. In quel caso, una VM o un host Linux nativo sono scelte più pulite.

La differenza pratica più importante è che WSL 2 gira dentro una VM leggera con rete virtualizzata. Questo significa che il comportamento di bind sulle porte, la visibilità da Windows e il riavvio dei servizi non sono identici a un server Linux classico. Se parti con questa aspettativa, eviti metà degli errori tipici.

Prerequisiti reali: WSL 2, distro Linux e aggiornamenti

Prima di installare Apache, verifica che stai usando WSL 2 e non WSL 1. Con WSL 1 la compatibilità è più limitata; con WSL 2 hai un kernel Linux vero e una base più sensata per i servizi. Da PowerShell, controlla lo stato delle distro installate.

wsl -l -v

Ti interessa vedere la colonna VERSION impostata a 2. Se trovi 1, la migrazione è semplice e reversibile.

wsl --set-version <NOME_DISTRO> 2

Dentro la distro Linux aggiorna prima l’indice dei pacchetti e il sistema base. Su Ubuntu/Debian la sequenza classica è questa:

sudo apt update
sudo apt upgrade -y

Se il tuo obiettivo è solo provare Apache, non serve complicare con stack extra. Installa prima il web server e valida che il servizio parta, poi aggiungi PHP o moduli extra solo se servono davvero.

Installazione di Apache nella distro WSL

Su Debian e Ubuntu il pacchetto si chiama apache2. L’installazione è lineare e non richiede passaggi particolari.

sudo apt install -y apache2

Dopo l’installazione, il primo controllo non deve essere il browser ma lo stato del servizio e i log recenti. In WSL, soprattutto nelle prime prove, è facile confondere un problema di avvio con un problema di rete.

sudo systemctl status apache2 --no-pager

Se systemd è abilitato nella tua distro WSL 2, il servizio dovrebbe risultare active (running). Se systemd non è attivo, Apache potrebbe non essere gestito come ti aspetti e devi usare il demone in foreground o abilitare systemd nella configurazione di WSL. Il file da controllare è /etc/wsl.conf.

[boot]
systemd=true

Dopo la modifica, chiudi tutte le sessioni WSL e riavvia la distro da Windows:

wsl --shutdown

Quando rientri nella shell Linux, ripeti il controllo del servizio. Se il demone non parte, il log è il prossimo punto da guardare.

journalctl -u apache2 -n 50 --no-pager

Verifica locale: la prova che conta è curl, non il browser

Il controllo più affidabile è una richiesta HTTP locale dalla distro WSL. Il browser di Windows può mascherare problemi di mapping o cache; curl ti dice subito se Apache risponde e con quale codice.

curl -I http://localhost/

Atteso: HTTP/1.1 200 OK o comunque una risposta valida del server. Se ottieni Connection refused, il problema è quasi sempre uno di questi: Apache non è in esecuzione, ascolta su un’altra porta, oppure la configurazione ha un errore sintattico.

sudo apache2ctl configtest

Questo comando deve restituire Syntax OK. Se fallisce, correggi prima la configurazione e solo dopo riprova il servizio. In WSL non ha senso inseguire il browser quando la config è già rotta.

Come raggiungere Apache da Windows 10

Con WSL 2, in molti casi http://localhost da Windows raggiunge direttamente il servizio esposto nella distro. È il percorso più semplice e quello da preferire per test locali. Se non funziona, verifica dove Apache sta ascoltando e su quale indirizzo.

sudo ss -ltnp | grep apache2

Se vedi 0.0.0.0:80 o 127.0.0.1:80, Apache è in ascolto sulla porta 80. Se vuoi esporlo anche verso la LAN, devi ragionare meglio su firewall, routing e superficie d’attacco. Per sviluppo locale, resta su localhost.

Se il sito non si apre da Windows ma funziona dentro WSL, il problema è quasi sempre di indirizzamento o di binding. In questo caso il test utile è confrontare l’IP della distro e la risposta del servizio.

hostname -I
ip addr show

Non fissarti sull’IP: con WSL 2 cambia e non va trattato come un server statico. Per questo, quando possibile, usa localhost e non IP hardcoded nei test.

DocumentRoot, permessi e file di prova

La cartella di default su Debian e Ubuntu è /var/www/html. Per una prova pulita crea un file semplice e verifica che Apache lo serva davvero. Questo evita di confondere un problema di PHP con un problema di web server.

echo '<h1>Apache in WSL funziona</h1>' | sudo tee /var/www/html/index.html

Poi richiedi la pagina da WSL e, se serve, dal browser Windows:

curl http://localhost/

Se il contenuto non cambia, controlla il virtual host attivo e il percorso del document root.

apache2ctl -S

Questo comando mostra quali virtual host sono caricati, su quali porte ascoltano e quale file di configurazione li definisce. È il modo più rapido per scoprire se stai modificando il file giusto o se un altro vhost sta intercettando la richiesta.

Virtual host: quando il test locale diventa realistico

Se vuoi simulare un sito vero, crea un virtual host dedicato. È il punto in cui WSL diventa utile per sviluppo serio: puoi testare nomi host, rewrite, directory index e separazione dei progetti senza sporcare la configurazione globale.

sudo nano /etc/apache2/sites-available/progetto.conf

Un esempio minimo:

<VirtualHost *:80>
    ServerName progetto.local
    DocumentRoot /var/www/progetto/public

    <Directory /var/www/progetto/public>
        AllowOverride All
        Require all granted
    </Directory>
</VirtualHost>

Abilita il sito e, se serve, il modulo rewrite.

sudo a2ensite progetto.conf
sudo a2enmod rewrite
sudo systemctl reload apache2

Per risolvere progetto.local senza toccare DNS esterni, modifica il file hosts di Windows:

C:\\Windows\System32\drivers\etc\hosts

Aggiungi una riga simile a questa:

127.0.0.1 progetto.local

È una modifica reversibile e limitata al tuo PC. Se la rimuovi, il nome smette di risolversi subito.

PHP in WSL con Apache: il caso più comune dopo il web server

Molti installano Apache e poi scoprono che la pagina PHP mostra il sorgente o un download invece di essere eseguita. In quel caso il problema non è Apache in sé, ma il modulo PHP o il collegamento tra Apache e PHP-FPM.

Per un setup classico con mod_php su Ubuntu/Debian, il percorso semplice è installare PHP e il modulo Apache.

sudo apt install -y php libapache2-mod-php

Poi verifica con un file di test minimale, senza mettere codice applicativo complesso all’inizio.

cat <<'EOF' | sudo tee /var/www/html/info.php
<?php phpinfo();
EOF

Se aprendo /info.php vedi la pagina PHP, l’integrazione funziona. Se vedi il testo grezzo, controlla che il modulo sia caricato.

apache2ctl -M | grep php

In ambienti moderni, su alcune distro, può essere preferibile PHP-FPM. In quel caso il ragionamento cambia: Apache fa da front-end e PHP gira separato. È più pulito quando vuoi allinearti a stack reali da hosting o produzione. Se ti serve questa strada, il controllo chiave diventa lo stato del socket FPM e la configurazione del proxy FastCGI.

Problemi tipici in WSL e come leggerli senza perdere tempo

Il primo errore classico è lanciare Apache e pensare che resti su anche dopo la chiusura della shell. In WSL, a seconda della configurazione, il comportamento dei servizi può cambiare. Per questo conviene testare sempre con un comando di stato e non dare per scontato il daemon persistente.

Il secondo errore è confondere il firewall di Windows con Apache. Se il servizio risponde su localhost ma non da un altro PC in rete, il problema può stare nel binding, nel firewall host o nella mancanza di una vera esposizione LAN. In sviluppo locale, questo non è un difetto: è una scelta di sicurezza sensata.

Il terzo errore è usare path Windows dentro la configurazione Linux o viceversa. Apache in WSL ragiona con filesystem Linux, quindi le directory devono essere coerenti con quella vista. Un percorso come C: emp non è un document root Linux valido; va tradotto nel mount corretto di WSL, oppure evitato del tutto.

Se trovi errori di permessi, il controllo da fare è semplice: il file esiste, il processo Apache può leggerlo, e il parent directory non blocca l’accesso. Una verifica utile è questa:

namei -l /var/www/progetto/public/index.html

Ti mostra il cammino completo e i permessi di ogni directory. È più utile di una diagnosi a occhio quando il sito restituisce 403.

Avvio automatico e manutenzione minimale

Se vuoi usare Apache in WSL con continuità, attiva systemd nella distro e gestisci il servizio come su una Linux normale. È la via più ordinata per avvio, restart e log. Senza systemd, ogni riapertura della distro può richiedere attenzione manuale.

Per l’aggiornamento del pacchetto Apache, resta sul canale della distro. Evita repository casuali se non hai un’esigenza precisa: in un ambiente WSL da sviluppo, la stabilità del packaging conta più dell’ultima versione assoluta.

sudo apt update
sudo apt install --only-upgrade apache2

Dopo gli aggiornamenti, il controllo minimo è sempre lo stesso: config test, stato servizio, risposta HTTP. Non serve fare di più se l’obiettivo è verificare che il setup resti sano.

Quando fermarsi e scegliere un’alternativa

Se devi esporre un sito a utenti reali, usare Apache in WSL su Windows 10 non è la soluzione che sceglierei. La combinazione introduce variabili inutili: lifecycle della distro, rete virtuale, dipendenza dal sistema host e un modello operativo che non coincide con il Linux server classico. Per sviluppo locale va bene; per una piattaforma stabile, no.

Se invece il tuo scopo è imparare Apache, testare una configurazione, verificare rewrite, moduli e virtual host, WSL è comodo e veloce. Ti consente di lavorare con file e comandi Linux restando su Windows, senza montare subito una VM completa. È questo il suo valore reale: abbassare il costo del test, non sostituire un server.

Regola pratica: se ti serve una sandbox, WSL va bene. Se ti serve un server, scegli un server vero.

Sequenza operativa consigliata, senza giri inutili

1. Verifica WSL 2 con wsl -l -v.
2. Aggiorna la distro con apt update e apt upgrade.
3. Installa Apache con apt install apache2.
4. Controlla il servizio con systemctl status apache2.
5. Valida la config con apache2ctl configtest.
6. Prova la risposta locale con curl -I http://localhost/.
7. Solo dopo aggiungi virtual host, PHP e nome host personalizzati.

Questa sequenza riduce il rumore diagnostico: ogni passo conferma un livello preciso, e quando qualcosa si rompe sai subito dove guardare. È il modo corretto di trattare Apache in WSL, senza trasformare una prova locale in un labirinto di problemi finti.