Installare Nginx su Ubuntu 22.04 LTS: guida manuale

Installare Nginx su Ubuntu 22.04 LTS senza passaggi inutili

Su Ubuntu 22.04 LTS, Nginx si installa in pochi minuti, ma la differenza tra un setup “funziona” e uno gestibile nel tempo sta nei dettagli: aggiornamento dell’indice pacchetti, verifica del servizio systemd, regole firewall coerenti e una configurazione virtual host che non costringa a interventi artigianali dopo il primo rilascio. Questa guida segue un percorso manuale, lineare e verificabile, adatto sia a una macchina nuova sia a un server già in uso su cui vuoi portare Nginx in modo controllato.

L’idea è semplice: installi il pacchetto, controlli che il demone sia attivo, verifichi l’ascolto sulle porte corrette, abiliti l’eventuale profilo UFW e poi costruisci un virtual host minimo ma corretto. Se qualcosa non torna, non si va avanti per supposizioni: si guarda lo stato del servizio, il log e la risposta HTTP locale prima di toccare altro.

Prerequisiti e contesto operativo

Questa procedura assume Ubuntu 22.04 LTS aggiornato, privilegi amministrativi tramite sudo e accesso SSH alla macchina. Se il server è dietro un firewall esterno, un security group cloud o un load balancer, la parte UFW non basta da sola: devi sempre considerare anche il controllo a monte della rete.

Prima di iniziare, conviene sapere se la macchina ospiterà solo Nginx come web server statico oppure se farà da reverse proxy verso PHP-FPM, Node.js o un backend applicativo. La differenza incide soprattutto sulla configurazione del server block e sulla diagnostica iniziale.

1. Aggiornare l’indice pacchetti e installare Nginx

Il primo passo è aggiornare la cache dei pacchetti e installare il pacchetto principale. Su Ubuntu 22.04 il repository ufficiale è sufficiente nella maggior parte dei casi, e per una installazione standard non serve aggiungere sorgenti esterne.

Esegui:

sudo apt update
sudo apt install -y nginx

Il primo comando allinea l’elenco dei pacchetti ai repository configurati; il secondo installa Nginx e i file di servizio systemd. Se il sistema è in uno stato sano, l’installazione termina senza errori e il servizio viene avviato automaticamente.

Per verificare che il pacchetto sia realmente presente, puoi controllare la versione installata:

nginx -v

Un output atteso è simile a nginx version: nginx/1.18.0 o una release successiva compatibile con il repository della tua distribuzione. Il numero esatto può cambiare con gli aggiornamenti di sicurezza, e non è un problema finché il pacchetto arriva dai repo Ubuntu.

2. Controllare stato, abilitazione e ascolto del servizio

Dopo l’installazione, la verifica utile non è “Nginx è installato?”, ma “sta ascoltando, è attivo e si riavvia correttamente al boot?”. In ambito server questa è la differenza tra una prova locale e un servizio affidabile.

Controlla lo stato con systemd:

sudo systemctl status nginx --no-pager

Lo stato desiderato è active (running). Se vedi failed o inactive, fermati qui e leggi l’ultima parte del log, perché andare avanti senza capire il motivo crea solo confusione.

Per vedere se il servizio è abilitato all’avvio automatico:

sudo systemctl is-enabled nginx

L’output corretto è enabled. Se non lo è, puoi abilitarlo senza cambiare altro:

sudo systemctl enable nginx

Per confermare che stia ascoltando sulla porta 80, usa uno di questi controlli:

sudo ss -ltnp | grep ':80'

curl -I http://127.0.0.1

Il primo deve mostrare un processo nginx in ascolto su 0.0.0.0:80 o [::]:80; il secondo deve restituire un codice HTTP come 200 OK o, subito dopo l’installazione, una pagina di default con intestazioni valide. Se curl fallisce in locale, il problema è sul nodo, non sulla rete esterna.

3. Aprire il firewall in modo coerente

Su Ubuntu, il firewall più comune lato host è UFW. Se è attivo, devi autorizzare il profilo “Nginx Full” o almeno HTTP in base al tuo scenario. Non dare per scontato che la porta sia raggiungibile solo perché il demone ascolta: il traffico può ancora essere bloccato localmente o da regole upstream.

Controlla lo stato di UFW:

sudo ufw status verbose

Se risulta Status: active, abilita il profilo appropriato:

sudo ufw allow 'Nginx Full'

Questo apre HTTP e HTTPS. Se vuoi limitarti alla sola porta 80 in fase iniziale, puoi usare:

sudo ufw allow 'Nginx HTTP'

La verifica utile è semplice:

sudo ufw status numbered

Devi vedere la regola appena inserita. Se il server è in cloud, controlla anche il firewall del provider: security group, network ACL o policy del bilanciatore. UFW aperto e porta ancora chiusa a monte è uno dei falsi positivi più comuni.

4. Capire la configurazione predefinita di Nginx

Su Ubuntu, la struttura tipica della configurazione ti porta a separare i file principali dai siti disponibili e abilitati. In genere trovi il file globale in /etc/nginx/nginx.conf, i virtual host in /etc/nginx/sites-available/ e i link attivi in /etc/nginx/sites-enabled/.

La pagina di default viene spesso servita da un server block già pronto. Prima di modificarlo, conviene capire cosa sta realmente caricando Nginx:

sudo nginx -T

Questo comando stampa la configurazione effettiva, inclusi i file inclusi da altri path. È più utile di un semplice cat perché ti mostra la vista finale che il demone usa davvero. Se c’è un errore di sintassi o un include mancante, lo vedi subito.

Se l’obiettivo è creare un sito nuovo, non conviene sovrascrivere il default a caso. Meglio creare un file dedicato e lasciare il default solo come riferimento o rimuoverlo in modo controllato dopo aver validato il nuovo server block.

5. Creare il primo virtual host manualmente

Per un dominio come example.com, il flusso pulito è: directory document root, file di configurazione dedicato, link simbolico in sites-enabled, test sintattico e reload. Questo riduce il rischio di errori e rende chiaro dove intervenire in futuro.

Prima crea la document root:

sudo mkdir -p /var/www/example.com/html

Imposta proprietà e permessi in modo conservativo. In genere www-data è l’utente del processo web su Ubuntu:

sudo chown -R www-data:www-data /var/www/example.com/html
sudo chmod -R 755 /var/www/example.com

Ora crea il server block in /etc/nginx/sites-available/example.com:

server {
    listen 80;
    listen [::]:80;

    server_name example.com www.example.com;

    root /var/www/example.com/html;
    index index.html index.htm;

    location / {
        try_files $uri $uri/ =404;
    }

    access_log /var/log/nginx/example.com.access.log;
    error_log /var/log/nginx/example.com.error.log;
}

Questa configurazione è volutamente essenziale: ascolta su IPv4 e IPv6, risponde solo per i nomi dichiarati, usa una root dedicata e scrive log separati. I log separati sono comodi quando hai più siti sulla stessa macchina e vuoi capire subito quale virtual host genera errori.

Abilita il sito con un link simbolico:

sudo ln -s /etc/nginx/sites-available/example.com /etc/nginx/sites-enabled/

Se il default interferisce, puoi disabilitarlo rimuovendo il link relativo, non il file sorgente:

sudo rm /etc/nginx/sites-enabled/default

Questo passaggio è reversibile perché il file resta in sites-available. È una buona abitudine: il rollback è un semplice ripristino del link, non una ricostruzione manuale del file.

6. Validare la sintassi prima di ricaricare

Con Nginx non si ricarica mai una configurazione nuova senza test. Il comando di validazione è rapido e ti risparmia un errore che, in produzione, può tradursi in un’interruzione evitabile.

sudo nginx -t

L’output corretto termina con syntax is ok e test is successful. Se compare un errore, il comando di solito indica file e riga. Correggi prima quello, poi ritesta. In un server con più siti, anche una parentesi mancante in un file secondario blocca tutto il demone.

Solo dopo il test positivo esegui il reload:

sudo systemctl reload nginx

Il reload è preferibile al restart perché ricarica la configurazione con impatto minore. Se invece hai cambiato moduli, binari o condizioni che richiedono un riavvio completo, devi valutare il caso specifico, ma per un virtual host standard il reload è la strada corretta.

7. Verificare il sito con una pagina minima

Per chiudere il cerchio, crea un file HTML minimale nella document root. Non serve niente di complesso: basta provare che Nginx stia servendo il contenuto giusto dal percorso giusto.

echo '<h1>Nginx su Ubuntu 22.04 LTS</h1>' | sudo tee /var/www/example.com/html/index.html

Poi prova localmente e, se il DNS è già pronto, anche dal nome host reale:

curl -i http://127.0.0.1
curl -i http://example.com

Nel primo caso vuoi vedere la risposta del server locale; nel secondo, un routing coerente con DNS e rete. Se il primo funziona e il secondo no, il problema non è Nginx ma il livello di name resolution o di raggiungibilità esterna.

8. Dove guardare se qualcosa non funziona

Quando il sito non risponde, la sequenza utile è sempre la stessa: servizio, log, porta, DNS, firewall. Saltare direttamente alla modifica della configurazione è il modo più rapido per perdere tempo.

I punti di controllo essenziali sono questi:

• Stato servizio: systemctl status nginx deve risultare active (running).
• Log errori: /var/log/nginx/error.log o il file specifico del virtual host deve mostrare un motivo leggibile.
• Ascolto porte: ss -ltnp deve mostrare Nginx su 80 e, se configurato, su 443.
• Risposta locale: curl -I http://127.0.0.1 deve restituire un codice HTTP coerente.
• Firewall esterno: UFW, security group o firewall del provider devono consentire il traffico in ingresso.

Se il problema è un errore di sintassi, nginx -t lo segnala. Se il problema è un conflitto di server block, nginx -T ti mostra quale configurazione viene caricata davvero. Se il problema è di rete, il servizio locale funziona ma la connessione remota fallisce: lì la diagnosi cambia livello.

9. Migliorie immediate da fare subito dopo l’installazione

Una volta che il sito base risponde, il passo successivo non è aggiungere complessità, ma mettere in ordine ciò che servirà tra una settimana. Due interventi sono quasi sempre sensati: log separati per host e preparazione del TLS se il sito sarà pubblico.

Per i log separati, hai già visto un esempio nel server block. Questo ti permette di filtrare rapidamente errori applicativi e accessi anomali. Per il TLS, il percorso più pulito su Ubuntu resta in genere Certbot o una PKI interna, ma la scelta dipende dal contesto. Se il dominio è esposto su Internet, HTTP puro è solo un passaggio temporaneo.

Se prevedi di usare PHP, non aggiungere subito direttive a caso. Prima definisci se vuoi php-fpm con socket locale, quale versione usare e quale root documenti. La parte web server e la parte runtime applicativo vanno tenute separate, altrimenti la diagnostica diventa inutile appena cresce la complessità.

10. Pulizia finale e criterio operativo

La sequenza corretta, in pratica, è sempre la stessa: installi, verifichi, apri il traffico, definisci il virtual host, testi la sintassi, ricarichi e solo dopo passi al contenuto reale. Questo approccio riduce gli errori e rende ogni passaggio reversibile.

Se vuoi sintetizzare il metodo in una regola sola, è questa: ogni modifica deve avere un controllo immediato e un rollback semplice. In Nginx significa file separati, link simbolici, test con nginx -t e reload al posto di restart quando possibile. È una disciplina banale solo in apparenza; in produzione evita gran parte dei disservizi gratuiti.

Assunzione operativa: il server è una macchina Ubuntu 22.04 LTS standard, con accesso amministrativo e rete coerente; se ci sono vincoli di cloud firewall, CDN o reverse proxy upstream, vanno verificati separatamente perché cambiano il punto reale di blocco.