Configurazione di Nginx che mantiene i siti veloci
Pubblicato il 19 settembre 2026
Un sito può sembrare perfettamente in salute finché un piccolo errore di configurazione di Nginx non trasforma un deploy di routine in un errore 502, un avviso SSL o un loop di reindirizzamento che non porta i visitatori da nessuna parte di utile. Nginx è veloce e affidabile, ma è anche rigoroso: una direttiva nel posto sbagliato può cambiare il modo in cui si comporta un intero sito. La buona notizia è che un approccio pulito rende la configurazione di Nginx molto meno misteriosa.
Questa guida si concentra sulle impostazioni più importanti quando si ospitano siti web: server block, gestione di PHP, HTTPS, reindirizzamenti, file statici, caching e test sicuri. Non hai bisogno di memorizzare ogni direttiva di Nginx. Devi capire quali decisioni influiscono sul tuo sito e come verificarle prima che influiscano sui tuoi visitatori.
Inizia con un layout chiaro della configurazione di Nginx
La maggior parte delle installazioni Linux separa le impostazioni globali dalle impostazioni dei singoli siti web. Il file di configurazione principale, che si trova comunemente in /etc/nginx/nginx.conf, controlla i processi worker, il logging, la compressione e le directory di configurazione incluse. I singoli siti di solito si trovano in una directory come sites-available, sites-enabled o conf.d.
Questa separazione è utile per un motivo pratico: le impostazioni globali devono essere modificate con attenzione e raramente, mentre le impostazioni a livello di sito richiedono attenzione regolare. Un nuovo dominio, un sito di staging o una regola di reindirizzamento appartengono al server block di quel sito, non al file principale.
Prima di modificare qualsiasi cosa, identifica la configurazione attiva e testala:
bash nginx -t
Se il test ha esito positivo, ricarica Nginx senza interrompere le connessioni attive:
bash systemctl reload nginx
Usa reload per le normali modifiche alla configurazione. A volte è necessario un riavvio completo, ma non è la prima mossa da fare quando aggiorni un virtual host. Piccole abitudini come questa impediscono che un'attività di cinque minuti diventi un intervento di recupero a tarda notte.
Crea un server block per ogni sito web
Un server block indica a Nginx quale dominio serve, dove sono archiviati i file del sito web e come devono essere gestite le richieste. Pensalo come il banco di accoglienza di un sito web. Quando più domini condividono un solo server, un server block ordinato è ciò che mantiene il traffico indirizzato al posto giusto.
Un sito HTTP di base potrebbe apparire così:
server {
listen 80;
server_name example.com www.example.com;
root /var/www/example.com/public;
index index.php index.html;
location / {
try_files $uri $uri/ /index.php?$query_string;
}
}
Il server_name dovrebbe elencare ogni hostname che intendi servire. Se i visitatori possono raggiungere sia il dominio root sia www, includili entrambi, quindi decidi quale dei due deve diventare canonico tramite un reindirizzamento.
Il percorso root deve puntare alla directory che contiene i file web pubblici, non necessariamente alla cartella di livello superiore del progetto. Per WordPress, spesso si tratta della cartella in cui esistono wp-admin, wp-content e wp-includes. Per Laravel e framework simili, in genere è la directory public. Puntare Nginx alla cartella sbagliata può esporre file che non dovrebbero mai essere disponibili pubblicamente.
La regola try_files merita attenzione. Controlla se un file o una directory richiesti esistono prima di passare all'applicazione le richieste non corrispondenti. Questo è essenziale per i permalink di WordPress e per molte moderne applicazioni PHP. Senza di essa, le pagine potrebbero funzionare solo quando i visitatori usano l'URL completo con index.php aggiunto. Non è l'ideale, e non è un problema che vuoi che siano i clienti a segnalarti per primi.
Evita la trappola del server predefinito
Nginx ha bisogno di un server predefinito per le richieste che non corrispondono a un hostname configurato. Se il sito sbagliato è impostato come predefinito, un dominio sconosciuto o una richiesta IP diretta possono mostrare il sito web di qualcun altro. Nel migliore dei casi è fonte di confusione, nel peggiore è rischioso.
Per i server multi-sito, usa un semplice server predefinito che non restituisca contenuti utili, ad esempio una risposta 404. Mantieni i siti web reali in server block espliciti con i propri valori server\_name. È un piccolo confine che rende un server condiviso più facile da gestire.
Configura PHP senza andare a tentativi
Nginx non elabora PHP da solo. Passa le richieste PHP a PHP-FPM, che esegue il codice. La connessione è normalmente un socket Unix o una porta TCP locale.
Un comune blocco location per PHP appare così:
location ~ \.php$ {
try_files $uri =404;
include fastcgi_params;
fastcgi_pass unix:/run/php/php8.3-fpm.sock;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
}
La versione di PHP e il percorso del socket variano in base al server. Se Nginx restituisce un errore 502 Bad Gateway dopo un aggiornamento di PHP, il percorso del socket è uno dei primi elementi da controllare. PHP-FPM potrebbe essere arrestato, eseguire una versione diversa o essere in ascolto in una posizione diversa dal percorso definito in Nginx.
Vale anche la pena mantenere la riga try_files $uri =404;. Impedisce a Nginx di inviare al processore PHP le richieste per file PHP inesistenti. Questo migliora sia la sicurezza sia la gestione degli errori.
Per WordPress, evita di aggiungere regole generiche copiate da post casuali di forum, a meno che tu non sappia perché sono necessarie. WordPress funziona già bene con una configurazione pulita di try_files, una corretta gestione di PHP e permessi di scrittura solo dove WordPress ne ha bisogno. Più regole non significano automaticamente una configurazione migliore.
Rendi HTTPS il percorso predefinito
Ogni sito web pubblico dovrebbe servire HTTPS e reindirizzare il traffico HTTP alla versione sicura. Lo schema usuale è un server block HTTP che esegue solo il reindirizzamento, più un block HTTPS separato che serve il sito.
server {
listen 80;
server_name example.com www.example.com;
return 301 https://example.com$request_uri;
}
Il server block HTTPS quindi rimane in ascolto sulla porta 443 e include i percorsi del certificato e della chiave privata. I file del certificato dipendono da come viene eseguito il provisioning di SSL, ma il principio resta lo stesso: mantieni la configurazione del certificato all'interno del sito che lo usa.
Un reindirizzamento permanente 301 è appropriato una volta che hai fiducia nella destinazione. Durante una migrazione attiva o un test a breve termine, un reindirizzamento 302 può essere più sicuro perché i browser non lo memorizzano nella cache in modo così aggressivo. Questo è uno di quei casi in cui l'opzione che sembra tecnicamente più forte non è sempre la scelta operativa giusta.
Scegli anche un hostname preferito. Reindirizza www al dominio root oppure il dominio root a www. Servirli entrambi senza un reindirizzamento coerente può frammentare le analisi, creare pagine duplicate per i motori di ricerca e rendere più difficile diagnosticare il comportamento dei cookie.
Servi i file statici in modo efficiente e sicuro
Immagini, CSS, JavaScript, font e file scaricabili non dovrebbero consumare risorse PHP quando Nginx può distribuirli direttamente. Imposta una cache del browser ragionevole per i file che cambiano di rado:
location ~* \.(css|js|jpg|jpeg|png|gif|svg|webp|ico|woff2)$ {
expires 30d;
add_header Cache-Control "public";
}
Trenta giorni sono un buon punto di partenza, non una legge. Se i nomi dei file includono numeri di versione o nomi file hashati, una cache più lunga può funzionare molto bene. Se lo stesso nome file viene sostituito frequentemente, una cache lunga può far sì che i visitatori vedano un design o uno script meno recente. La cache è sempre un compromesso tra velocità e rapidità con cui i cambiamenti devono apparire.
Non esporre file nascosti per errore. Una semplice regola può bloccare le richieste per i dotfile consentendo al tempo stesso la directory .well-known usata dalla convalida del certificato:
location ~ /\.(?!well-known(?:/|$)) {
deny all;
}
A seconda della configurazione del certificato, potresti aver bisogno di un'eccezione specifica per .well-known. Testa il comportamento del rinnovo dopo aver reso più restrittive le regole di accesso. Le regole di sicurezza dovrebbero ridurre l'esposizione, non interrompere silenziosamente i servizi su cui fai affidamento.
Usa gli header di sicurezza con contesto
Gli header di risposta possono migliorare la protezione dal lato browser, ma richiedono test. Esempi comuni includono X-Content-Type-Options nosniff, Referrer-Policy e Content-Security-Policy. L'ultimo è potente e facile da configurare male. Una policy rigorosa può bloccare script, font, widget di pagamento, analisi o contenuti incorporati se viene introdotta senza comprendere le dipendenze del sito.
Inizia con header che hanno uno scopo chiaro e un rischio basso, quindi aggiungi una content security policy in modalità report-only se la tua applicazione la supporta. L'obiettivo non è raccogliere un impressionante stack di direttive. L'obiettivo è ridurre il rischio reale senza compromettere le pagine che le persone devono usare.
Anche il rate limiting può aiutare contro il traffico abusivo e gli attacchi ai login, soprattutto per gli endpoint di accesso di WordPress. Ma limiti aggressivi possono bloccare utenti legittimi dietro reti d'ufficio condivise o operatori mobili. Esamina i log e regolati in base ai modelli di traffico reali invece di scegliere numeri che sembrano soltanto severi.
Testa i cambiamenti come se contassero
Ogni modifica a Nginx dovrebbe seguire la stessa breve routine: esegui un backup o copia il file corrente, apporta una sola modifica mirata, esegui nginx -t, ricarica Nginx e testa il sito web da un browser e dalla riga di comando. Controlla il dominio previsto, il dominio non canonico, HTTP, HTTPS e una pagina gestita da PHP.
Quando qualcosa non funziona, leggi i log degli errori prima di riscrivere la configurazione. I log di accesso e di errore di Nginx spesso rivelano se il problema è un file mancante, un permesso errato, una connessione upstream fallita o un reindirizzamento sbagliato. Andare a tentativi può creare tre nuovi problemi senza risolverne nessuno.
Un pannello di controllo può eliminare gran parte di questo lavoro manuale creando e organizzando in un unico posto impostazioni a livello di sito web, certificati, versioni di PHP e log. FASTPANEL è progettato per questa pratica via di mezzo: mantieni il controllo del tuo ambiente di hosting senza trasformare ogni modifica di dominio in un progetto di archeologia della configurazione.
Una buona configurazione di Nginx non consiste nel creare il file più lungo o nell'usare ogni direttiva disponibile. Si tratta di rendere ogni sito prevedibile: il dominio giusto raggiunge i file giusti, PHP ha un upstream sano, HTTPS è applicato, il contenuto statico è efficiente e i cambiamenti vengono testati prima che i visitatori li incontrino. Una volta che queste fondamenta sono a posto, gestire un server in crescita diventa molto meno drammatico - esattamente come dovrebbe essere.