Come installare Nginx su Ubuntu 22.04 -- TrgtKLS • Tech, Sicurezza e Strumenti & guide per Webmaster

1 1 visite 13/04/2026 Pubblicato il: 13/04/2026 14:33 Tempo di lettura: 10 min

Su Ubuntu 22.04 Nginx si installa in pochi minuti, ma il punto non è “far partire il pacchetto”: è portarlo in uno stato pulito, verificabile e pronto per ospitare siti o reverse proxy senza lasciare buchi inutili. Se lo tratti come un componente di produzione fin dall’inizio, eviti di ritrovarti con un server che risponde in locale ma resta invisibile da rete, con il firewall che blocca la porta 80, o con una configurazione sparsa in file non più gestibili.

Il percorso corretto è lineare: aggiornare gli indici, installare il pacchetto, controllare il servizio systemd, aprire le porte necessarie solo se servono, poi costruire un virtual host minimale e testarlo con una richiesta reale. Da lì si passa a TLS, logging e manutenzione. Non serve fare tutto in una volta, ma conviene sapere dove si va a finire: Nginx non è solo un demone HTTP, è spesso il primo punto di contatto tra utenti e applicazione.

Installazione del pacchetto su Ubuntu 22.04

Il primo passo è aggiornare la cache dei pacchetti e installare Nginx dal repository ufficiale di Ubuntu. Su Jammy il pacchetto è stabile e integrato con systemd, quindi non serve aggiungere repository esterni per un’installazione standard.

Esegui questi comandi:

sudo apt update
sudo apt install nginx

Dopo l’installazione, verifica che il servizio sia attivo e abilitato all’avvio automatico:

systemctl status nginx --no-pager
systemctl is-enabled nginx

L’esito atteso è active (running) per lo stato del servizio e enabled per l’avvio automatico. Se il servizio non parte, il primo controllo non è la reinstallazione: è il log di systemd e la presenza di un eventuale conflitto sulla porta 80 o 443.

Per vedere gli errori recenti:

journalctl -u nginx -n 50 --no-pager

Se compare un errore di binding, spesso c’è già un altro web server in ascolto. Il comando rapido per verificarlo è:

ss -ltnp | grep -E ':(80|443)\s'

Qui non stai ancora correggendo nulla: stai solo verificando che Nginx abbia spazio per ascoltare senza collisioni.

Verifica del servizio e pagina di default

Una volta avviato, Nginx espone di default una pagina di benvenuto. Da locale o da un host che raggiunge il server, prova:

curl -I http://127.0.0.1
curl -I http://IP_DEL_SERVER

Se tutto è corretto, la risposta deve contenere HTTP/1.1 200 OK o comunque un codice di successo e l’header Server: nginx. Se da localhost risponde ma dall’esterno no, il problema è quasi sempre nel firewall, nella security group del cloud o nel routing di rete, non in Nginx.

La pagina di default si trova in genere in /var/www/html, mentre la configurazione del sito predefinito è sotto /etc/nginx/sites-available/default con link simbolico in /etc/nginx/sites-enabled/. Questo dettaglio è importante perché su Ubuntu la gestione dei siti passa da file separati, non da un unico blocco monolitico.

Firewall: aprire solo ciò che serve

Se il server usa UFW, devi autorizzare il traffico HTTP e, se prevedi TLS, anche HTTPS. Non aprire porte a caso: Nginx lavora bene anche con una superficie esposta minima.

sudo ufw status verbose
sudo ufw allow 'Nginx Full'

Il profilo Nginx Full apre 80 e 443. Se vuoi solo testare HTTP in una fase iniziale, puoi usare il profilo Nginx HTTP, ma è una scelta temporanea. Dopo la modifica, controlla di nuovo lo stato:

sudo ufw status numbered

Se il server è in cloud, ricorda che il firewall locale non basta: la porta deve essere permessa anche nel pannello del provider o nel security group. Quando un curl locale funziona e dall’esterno no, il colpevole è spesso lì.

Struttura dei file di configurazione su Ubuntu

Su Ubuntu conviene rispettare la separazione tra file disponibili e file abilitati. In pratica, la configurazione vive in /etc/nginx/sites-available/ e viene attivata con un link simbolico in /etc/nginx/sites-enabled/. Questo permette rollback rapidi e riduce il rischio di modifiche sparse.

Prima di toccare un file esistente, fai una copia di sicurezza:

sudo cp /etc/nginx/sites-available/default /etc/nginx/sites-available/default.bak

È una misura semplice, ma utile quando stai lavorando su un host remoto. Se qualcosa va storto, il ripristino è immediato:

sudo cp /etc/nginx/sites-available/default.bak /etc/nginx/sites-available/default
sudo nginx -t
sudo systemctl reload nginx

La regola pratica è questa: ogni modifica a Nginx va seguita da nginx -t prima del reload. Saltare il test è il modo più rapido per introdurre un downtime evitabile.

Creare un virtual host minimale

Per un sito statico o per preparare un reverse proxy, il modo pulito è creare un file dedicato. Per esempio, supponiamo di voler servire example.com. Crea la directory del sito e un file HTML di prova:

sudo mkdir -p /var/www/example.com/html
sudo chown -R $USER:$USER /var/www/example.com/html
cat > /var/www/example.com/html/index.html <<'EOF'
<html>
<body>
<h1>Nginx su Ubuntu 22.04</h1>
</body>
</html>
EOF

Ora crea la configurazione del server block:

sudo nano /etc/nginx/sites-available/example.com

Contenuto minimo consigliato:

server {
    listen 80;
    listen [::]:80;
    server_name example.com www.example.com;

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

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

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

Abilita il sito con il link simbolico e disabilita il default se non ti serve:

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

Prima di ricaricare il servizio, controlla la sintassi:

sudo nginx -t

Se il test è OK, applica il reload senza interrompere le connessioni attive:

sudo systemctl reload nginx

A questo punto verifica con una richiesta HTTP reale:

curl -I http://example.com
curl http://example.com

Il risultato atteso è la tua pagina HTML, non la pagina di default di Ubuntu. Se vedi ancora il default server, di solito c’è un problema di server_name, di link in sites-enabled o di priorità del virtual host.

Permessi, utente web e directory corrette

Su Ubuntu il processo Nginx gira in genere come www-data. Questo significa che i file serviti devono essere leggibili da quell’utente, ma non per forza scrivibili. Per un sito statico bastano permessi di lettura adeguati sulla catena di directory.

namei -l /var/www/example.com/html/index.html
ls -ld /var/www /var/www/example.com /var/www/example.com/html

Se il contenuto deve essere aggiornato da un utente diverso, conviene separare proprietà e gruppo in modo coerente, invece di aprire tutto a 777. Quella scorciatoia ti evita un errore oggi e te ne crea due domani.

Un controllo utile è verificare che Nginx possa leggere il file senza errori di permesso:

sudo -u www-data test -r /var/www/example.com/html/index.html && echo OK

Se risponde OK, il problema non è il filesystem. Se fallisce, correggi ownership o ACL prima di guardare altrove.

Abilitare TLS con Let’s Encrypt

Una volta che il sito risponde su HTTP, il passaggio successivo è mettere TLS. Su Ubuntu 22.04 il percorso più pratico è Certbot con il plugin per Nginx. È una scelta sensata per la maggior parte dei casi standard, perché automatizza sia il certificato sia la parte di configurazione del server block.

sudo apt install certbot python3-certbot-nginx
sudo certbot --nginx -d example.com -d www.example.com

Durante la procedura Certbot può proporre il redirect da HTTP a HTTPS. In produzione, salvo esigenze particolari, è l’impostazione giusta perché riduce ambiguità e forza un solo percorso di accesso.

Dopo l’emissione, controlla il rinnovo automatico:

systemctl status certbot.timer --no-pager
sudo certbot renew --dry-run

Il dry-run è la verifica che ti interessa davvero: se fallisce, non aspettare la scadenza del certificato per accorgertene. Il rinnovo automatico deve essere testato, non solo assunto.

Logging e diagnosi rapida

Quando qualcosa non va, Nginx lascia tracce precise. Gli access log e gli error log sono la base della diagnosi. Su una configurazione standard li trovi sotto /var/log/nginx/, ma nei server block personalizzati conviene separare i log per dominio o applicazione.

sudo tail -n 50 /var/log/nginx/error.log
sudo tail -n 50 /var/log/nginx/access.log

Se ricevi un 502 Bad Gateway, il problema di solito non è Nginx in sé ma il backend upstream: PHP-FPM, un’app Node, un servizio Python, o un socket non raggiungibile. In quel caso il controllo minimo è il socket o la porta del servizio dietro Nginx.

ss -ltnp
systemctl status php8.1-fpm --no-pager

Il principio resta lo stesso: Nginx è spesso il sintomo visibile, non la causa ultima. I log ti dicono dove si interrompe il flusso.

Reverse proxy: il caso più frequente in produzione

Molto spesso Nginx non serve contenuti statici, ma fa da reverse proxy verso un’applicazione interna. È uno scenario comune perché separa il front-end HTTP dal motore applicativo e permette di gestire TLS, compressione, header e buffering in un punto unico.

Un esempio minimo:

server {
    listen 80;
    server_name app.example.com;

    location / {
        proxy_pass http://127.0.0.1:3000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

Qui il controllo da fare non è solo “Nginx risponde”, ma anche “l’app dietro risponde sulla porta giusta”. Se il backend cade, il front-end restituisce errori 502 o 504. La verifica base è semplice:

curl -I http://127.0.0.1:3000

Se questo comando fallisce, risolvi prima il servizio applicativo. Nginx non può mascherare un backend assente in modo stabile.

Prestazioni essenziali da controllare

Per un’installazione pulita la metrica base non è “quanti moduli hai caricato”, ma la latenza percepita e la stabilità sotto carico leggero. Le prime cose da osservare sono TTFB, tasso di errore e saturazione di CPU e connessioni. Su un server appena installato, il collo di bottiglia di solito non è Nginx ma la configurazione del backend o del disco.

Un controllo rapido dello stato del nodo:

uptime
free -h
iostat -xz 1 3

Se i tempi di risposta crescono, ma la CPU resta bassa e il disco è tranquillo, il problema può essere la rete, il DNS, il TLS handshake o l’applicazione dietro il proxy. Se invece il disco è saturo o il sistema va in swap, il problema è più a valle e Nginx ne paga solo il prezzo.

Manutenzione e aggiornamenti

Nginx su Ubuntu riceve aggiornamenti tramite il normale ciclo di apt. In un ambiente serio, gli update non si fanno “quando capita”: si fanno con una finestra minima, controllo post-update e rollback pronto se la configurazione o i moduli cambiano comportamento.

sudo apt update
sudo apt upgrade nginx

Dopo l’upgrade, esegui almeno questi controlli: sintassi, stato del servizio, risposta HTTP e log errori. Se hai personalizzazioni importanti, conserva la configurazione in version control o almeno in un backup timestampato. Il file che ti interessa davvero è quello in /etc/nginx/, non il pacchetto in sé.

Se devi fare un cambiamento più ampio, come introdurre gzip, cache header, rate limiting o nuove location, applica sempre la sequenza: modifica minima, nginx -t, reload, verifica con curl, poi osservazione dei log. È il ciclo più robusto e meno rumoroso per lavorare su un web server in produzione.

Sequenza pratica consigliata

Se vuoi una traccia operativa sintetica, la sequenza migliore è questa:

Installa il pacchetto con apt e verifica che il servizio sia active.
Controlla con curl -I la risposta su localhost e sull’IP pubblico.
Apri nel firewall solo le porte necessarie.
Crea un virtual host dedicato in /etc/nginx/sites-available/.
Abilita il sito con il link simbolico in sites-enabled.
Esegui nginx -t prima di ogni reload.
Passa a TLS con Certbot e verifica il rinnovo.
Monitora log e stato del backend se usi reverse proxy.

Questa sequenza evita il classico errore di “installato ma non raggiungibile”, che in realtà nasce quasi sempre da un dettaglio di rete, firewall o configurazione del server block. Nginx è rapido da mettere online; la parte professionale è tenerlo leggibile, testabile e facile da ripristinare quando cambi qualcosa.