Corso Linux / Installare Nginx e pubblicare un sito con HTTP e HTTPS

Linux

Pubblicato 2026-11-04 Ultima modifica 2026-11-04

Per pubblicare un sito con Nginx devono essere coerenti file, configurazione, porte in ascolto, firewall, DNS e certificato TLS. Verifica prima la pagina via HTTP sul server, poi l’accesso da un’altra macchina e il dominio reale; aggiungi HTTPS solo dopo questi controlli e verifica anche il rinnovo del certificato.

Per gli errori di connessione usa la diagnosi dei livelli di rete; prima dell’esposizione applica la protezione di account e firewall. Le versioni di Nginx e degli strumenti per i certificati dipendono dai repository: registra quelle installate e segui la documentazione adatta alla distribuzione.

Il riferimento è una VM con installazione ordinaria di Ubuntu 26.04 LTS oppure Rocky Linux 9. Container, WSL e altre versioni possono avere servizi e pacchetti differenti. Prepara console di recupero e verifica delle versioni seguendo la lezione sulla macchina virtuale di prova, in inglese.

Preparare server, nome e condizioni di accesso

Servono un server di laboratorio Ubuntu o Rocky Linux, un account sudo e una console di recupero. linux-course.test è un nome per prove locali, da non registrare nel DNS pubblico. Per la pubblicazione userai un dominio reale sotto il tuo controllo. Se il server è dietro NAT, verifica inoltro delle porte, indirizzo pubblico del router ed eventuali restrizioni del fornitore. Controlla innanzitutto se altri servizi occupano le porte 80 o 443:

sudo ss -lntp
cat /etc/os-release

La porta 80 è usata normalmente da HTTP; la 443 da HTTPS, cioè HTTP protetto da TLS, Transport Layer Security. Annotare un listener non significa autorizzare il traffico nel firewall. Non arrestare un servizio esistente per liberare la porta senza averne valutato l’uso.

Installare Nginx dalla distribuzione scelta

Usa soltanto il blocco della tua distribuzione, leggi la transazione proposta e rispetta la politica dei repository. Su Ubuntu:

sudo apt update &&
sudo apt install nginx curl &&
sudo systemctl enable --now nginx

Su Rocky Linux:

sudo dnf install nginx curl &&
sudo systemctl enable --now nginx

La catena && evita di avviare il servizio dopo un comando fallito; non annulla pacchetti già installati né modifiche già riuscite. enable --now abilita il servizio all’avvio e tenta di avviarlo subito. Controlla il risultato con systemctl status nginx --no-pager e la versione con nginx -v. Una pagina predefinita funzionante non dimostra che il nuovo sito sia configurato: aggiungerai un blocco separato senza eliminare gli altri siti.

Creare una radice documenti e un blocco server completo

Prima di eseguire l’esempio, controlla /var/www/linux-course e /etc/nginx/conf.d/linux-course.conf, compresi eventuali collegamenti simbolici. Se esistono già, fermati, conserva un backup e scegli nomi nuovi aggiornando tutti i riferimenti: tee sovrascrive i file e questo blocco non è un aggiornamento sicuro di un sito esistente. Conserva anche una copia della configurazione Nginx corrente.

L’esempio presuppone che nginx.conf includa conf.d/*.conf nel contesto http. Verifica la struttura effettiva, eventualmente con sudo nginx -T, prima di aggiungere il file; l’output può contenere dettagli operativi e non va pubblicato integralmente. La directory /var/www/linux-course conterrà soltanto la pagina statica di prova.

(
set -o pipefail
sudo install -d -m 755 /var/www/linux-course &&
printf '<!doctype html><html lang="it"><meta charset="utf-8"><title>Corso Linux</title><h1>Il server del corso Linux funziona</h1></html>\n' | sudo tee /var/www/linux-course/index.html &&
sudo chmod 644 /var/www/linux-course/index.html &&
sudo tee /etc/nginx/conf.d/linux-course.conf > /dev/null <<'EOF' &&
server {
    listen 80;
    server_name linux-course.test;
    root /var/www/linux-course;
    index index.html;
    location / {
        try_files $uri $uri/ =404;
    }
}
EOF
sudo nginx -t
)

La pagina generata ha testo e attributo lang in italiano. Il suo h1 è il titolo dell’HTML servito dal laboratorio, non un titolo dentro questo articolo WordPress. Le virgolette in <<'EOF' conservano letteralmente $uri nel file Nginx. La subshell limita pipefail al blocco; se una fase fallisce, i comandi successivi non partono, ma possono restare file parziali da controllare.

Secondo la guida introduttiva di Nginx, le modifiche diventano attive al reload. Correggi prima gli errori di file e riga segnalati da nginx -t. Quando il controllo riesce, esegui:

sudo nginx -t &&
sudo systemctl reload nginx &&
curl -i --resolve linux-course.test:80:127.0.0.1 http://linux-course.test/

curl -i può terminare con codice zero anche ricevendo un errore HTTP: leggi lo stato e il corpo. Attendi HTTP 200 e il testo Il server del corso Linux funziona. --resolve fornisce a curl la corrispondenza nome-indirizzo per quella richiesta, senza modificare il DNS del sistema. Se l’ambiente usa un proxy HTTP, escludi esplicitamente questa prova locale dal proxy secondo la sua configurazione. Se compare la pagina predefinita, verifica nome richiesto, server_name e configurazione caricata: la selezione del server Nginx dipende prima da indirizzo e porta, poi dal nome Host.

Distinguere permessi dei file ed esposizione in rete

Su Rocky Linux con SELinux attivo controlla ls -Zd /var/www/linux-course. Per un percorso previsto dalla politica standard puoi ripristinare le etichette con sudo restorecon -Rv /var/www/linux-course; percorsi non standard possono richiedere una regola persistente. Consulta la gestione SELinux di Rocky Linux. Non risolvere un 403 disattivando SELinux o assegnando permessi 777 a tutto il percorso: verifica lettura dei file, attraversamento delle directory e log del rifiuto.

Dopo il test locale consenti HTTP su 80/tcp e, quando necessario, HTTPS su 443/tcp nell’ambito previsto. Con UFW una regola come sudo ufw allow 80/tcp apre la porta a tutte le sorgenti previste dalla regola: se serve un accesso ristretto, specifica invece la sorgente autorizzata. Con firewalld identifica la zona dell’interfaccia, prova i servizi http e https nella configurazione runtime e rendi permanenti solo le regole approvate. Segui la procedura dettagliata della lezione sul firewall collegata sopra, mantieni SSH e controlla separatamente le regole cloud.

Da un altro computer usa curl -H "Host: linux-course.test" http://INDIRIZZO_REALE/, sostituendo il segnaposto con l’indirizzo del server raggiungibile da quel client. Deve comparire la stessa pagina. Successo locale e fallimento remoto indirizzano verso binding, firewall, route e NAT. Una risposta 403, 404 o 502 indica che hai raggiunto un interlocutore HTTP: individua quale server l’ha prodotta e indaga permessi, percorso o applicazione, senza cambiare il firewall per tentativi.

Collegare il dominio reale e abilitare HTTPS

Imposta il record A del dominio sull’indirizzo IPv4 pubblico corretto. Aggiungi AAAA soltanto se il server e la rete gestiscono davvero IPv6. Il blocco mostrato usa listen 80 per IPv4: per IPv6 occorrono anche un listener appropriato, per esempio listen [::]:80; nello stesso blocco, e regole coerenti. Controlla i conflitti con le configurazioni esistenti.
Sostituisci linux-course.test in server_name con il dominio reale, controlla con sudo nginx -t e applica un reload solo se riesce. Da un’altra rete prova HTTP tramite quel dominio, senza --resolve, verificando così anche la risoluzione DNS utilizzata dal client.
Nelle istruzioni ufficiali Certbot seleziona Nginx e il sistema installato. Scegli un solo metodo di installazione. Se usi i pacchetti Ubuntu disponibili nei repository configurati, il comando è sudo apt install certbot python3-certbot-nginx; su Rocky verifica prima i repository e i pacchetti richiesti. Controlla certbot --version e la presenza del plugin Nginx con sudo certbot plugins.
Fai un backup della configurazione prima che Certbot la modifichi. Per il dominio reale raggiungibile esegui sudo certbot --nginx -d DOMINIO_REALE, sostituendo il segnaposto e seguendo le richieste. Con il plugin Nginx la verifica HTTP-01 richiede che l’autorità raggiunga la porta pubblica 80; la sola 443 aperta non basta. La 443 serve invece per offrire HTTPS.
Da un altro client verifica curl -I https://DOMINIO_REALE/ senza disattivare il controllo del certificato e apri il sito nel browser: controlla pagina, nome del certificato, catena di fiducia e scadenza. Verifica inoltre curl -I http://DOMINIO_REALE/ e la destinazione dell’eventuale redirect HTTPS. Una risposta HEAD conferma le intestazioni, non il contenuto completo.
Consulta sudo certbot certificates per il nome effettivo del certificato e prova sudo certbot renew --cert-name NOME_CERTIFICATO --dry-run per limitare il test a questo certificato. Controlla anche il timer o il processo pianificato previsto dal metodo d’installazione: un dry-run riuscito non prova che la pianificazione sia attiva.

Il dry-run usa normalmente il servizio di prova di Let’s Encrypt, può attivare hook e reload temporanei e va pianificato anche se non conserva il certificato di prova. Per dettagli e differenze fra versioni consulta la guida Certbot su plugin e rinnovi. Se HTTP-01 non è praticabile, valuta un metodo supportato come DNS-01, che richiede il corretto record TXT e una strategia di rinnovo; le verifiche di dominio di Let’s Encrypt descrivono le condizioni. Non confondere il completamento locale con la pubblicazione HTTPS e non inviare password o token durante le prove HTTP non cifrate.

Diagnosticare gli errori e ripristinare solo il laboratorio

systemctl status nginx --no-pager
journalctl -b -u nginx -n 50 --no-pager
sudo nginx -t

Consulta anche il percorso error_log configurato e l’orario della richiesta. I messaggi possono richiedere privilegi aggiuntivi per la lettura; un accesso negato ai log non equivale all’assenza di errori. Uno stato del servizio non attivo produce uno stato di uscita non nullo: esamina il risultato prima di proseguire.

Per ritirare il laboratorio, conserva una copia e rimuovi soltanto il file conf creato per esso, poi verifica con nginx -t e fai reload solo dopo esito positivo. Se Certbot ha aggiunto altri riferimenti, esaminali prima di rimuovere file o certificati. Pulisci documenti, DNS e regole del firewall solo dopo averne verificato le dipendenze e limita ogni rimozione alle risorse aggiunte per la prova. Non eliminare siti esistenti, certificati condivisi o regole SSH.

Documentazione ufficiale

Linux