Gestire più siti web con Nginx Server Blocks (Virtual Hosts): guida completa

I server blocks di Nginx rappresentano il concetto dei “virtual hosts”, ovvero la possibilità di pubblicare diversi domini o siti web con configurazioni distinte su una sola installazione di Nginx. Ad esempio, puoi avere example.com, blog.example.com e secondo-sito.com sulla stessa VPS, ciascuno con directory root, file di log, certificati SSL e impostazioni PHP dedicate. In breve: si crea una directory separata per ogni sito, si configura il DNS del dominio verso l’IP del server, si scrive un server block dedicato in /etc/nginx/sites-available, si attiva tramite link simbolico nella directory sites-enabled, si testa la configurazione e si ricarica il servizio Nginx.

Questa guida affronta il processo di hosting multi-sito con Nginx server blocks in modo adatto a un ambiente di produzione. L’obiettivo non è solo avere una soluzione funzionante, ma anche creare una struttura gestibile, sicura, veloce, facilmente backuppabile e scalabile. Condivideremo passaggi pratici particolarmente utili ad agenzie, sviluppatori, proprietari di e-commerce, aziende che gestiscono più brand e amministratori di sistema che mantengono vari progetti su un solo server. Se non hai ancora un server, consulta le pagine server VPS per la scelta delle risorse e Registrazione del Dominio per la gestione dei domini.

Cosa sono i Nginx Server Blocks?

I server blocks di Nginx sono sezioni di configurazione (server block) che determinano a quale sito deve essere indirizzata una richiesta HTTP/HTTPS. Questo concetto è analogo ai VirtualHost di Apache. Quando un utente digita un dominio nel browser, il DNS risolve il nome nell’IP del server; Nginx controlla l’header Host della richiesta e attiva il server block il cui valore server_name corrisponde.

Così puoi pubblicare decine di siti diversi sullo stesso IP e server fisico o virtuale. Ogni sito può avere root directory, log di accesso ed errore, regole di redirect, certificato SSL, policy di caching e regole di sicurezza proprie. Ad esempio, puoi tenere il sito aziendale in /var/www/azienda/public, il blog in /var/www/blog/public e l’ambiente di test in /var/www/staging/public.

Nginx eccelle in questo tipo di struttura grazie alla sua architettura event-driven, che permette di gestire molte connessioni simultanee con un basso consumo di risorse. Per questo è molto usato su hosting condiviso, VPS, cloud server e infrastrutture ad alto traffico. Per garantire un funzionamento stabile multi-sito, è fondamentale pianificare correttamente ogni dettaglio: permessi sui file, DNS, installazione SSL, separazione dei log, ecc.

Quando si usano i server blocks su Nginx?

I server blocks di Nginx sono essenziali quando devi gestire più siti web sullo stesso server. Può trattarsi di due siti aziendali, oppure decine di progetti clienti, sottodomini o microservizi. La chiave è separare logicamente ogni progetto.

• Vuoi pubblicare più domini sulla stessa VPS.
• Desideri indirizzare www e non-www verso un unico indirizzo canonico.
• Hai bisogno di collegare sottodomini a directory o applicazioni diverse.
• Vuoi definire certificato SSL e policy di sicurezza distinti per ogni sito.
• Devi monitorare i progetti clienti con log separati.
• Vuoi eseguire Laravel, WordPress, HTML statico e Node.js sullo stesso server.

Ad esempio, un’agenzia digitale può ospitare 8 siti aziendali a basso traffico su una sola VPS da 4GB RAM. Ma occorre valutare traffico, uso disco, processi PHP, carico database e frequenza backup per ogni sito. Se i progetti ricevono molto traffico o serve isolamento delle risorse, meglio optare per VPS più potenti, cloud server o hosting gestito. Qui puoi confrontare Web Hosting e Hosting Aziendale.

Prerequisiti prima di iniziare

Questa guida presuppone un server Linux Ubuntu/Debian. I comandi possono variare leggermente su altre distribuzioni, ma il principio resta identico. Prima di operare in produzione, esegui sempre un backup: una configurazione errata di Nginx può rendere tutti i siti temporaneamente irraggiungibili.

Preparazione tecnica necessaria

• Account Linux con privilegi root o sudo.
• Servizio Nginx installato e funzionante.
• Almeno un dominio puntato sull’IP del server.
• Firewall con porte 80 e 443 aperte.
• Struttura ordinata delle directory per i file dei siti.
• Certificato SSL valido o Let’s Encrypt gratuito.
• Installazione PHP-FPM per applicazioni PHP.

Dal lato DNS, il record A punta il dominio principale all’IPv4, AAAA all’IPv6. Per www o altri sottodomini si usano record CNAME o A. La propagazione DNS dura da pochi minuti a 24 ore. Prepara i record prima, poi passa alla configurazione di Nginx: così velocizzi tutto il processo.

Struttura consigliata delle directory

Uno degli errori più comuni nell’hosting multi-sito è tenere tutti i file mescolati in una sola directory. Sembra pratico all’inizio, ma complica manutenzione, backup e debug. Meglio usare una directory principale per ogni dominio, con sottocartelle public, logs, backups ecc.

Esempio: /var/www/sito1.com/public, /var/www/sito1.com/logs, /var/www/sito2.com/public, /var/www/sito2.com/logs. Il parametro root di Nginx deve puntare alla sola public. Così file di applicazione, .env e backup non sono accessibili direttamente dal web.

Per un test statico, inserisci un file index.html in ogni cartella, indicando il nome del sito: così verifichi rapidamente quale server block è attivo. In produzione, la proprietà delle cartelle è di solito assegnata a www-data o a un utente dedicato. Di norma, permessi 755 per le cartelle e 644 per i file sono sufficienti. Per WordPress o altre app che scrivono su disco, valuta permessi specifici per uploads.

Creare un Nginx server block: step by step

Ecco i passaggi, esemplificati su sito1.com. Ripeti lo stesso metodo per altri siti, cambiando server_name, root e log.

1. Crea la directory del sito

Prima, crea la cartella per i file web. Esempio: sudo mkdir -p /var/www/sito1.com/public. Poi crea /var/www/sito1.com/public/index.html con un messaggio come “Questa è la pagina di test di sito1.com”.

Assegna la proprietà corretta con sudo chown -R www-data:www-data /var/www/sito1.com. Se deployi con un altro utente, regola i permessi di gruppo. Evita assolutamente permessi 777: sono rischiosi e permettono agli attaccanti di abusare delle directory di upload.

2. Crea il file di configurazione del server block

La prassi è tenere le configurazioni inattive in /etc/nginx/sites-available, attivarle tramite link simbolico in /etc/nginx/sites-enabled. File esempio: /etc/nginx/sites-available/sito1.com.

Configurazione base HTTP:

server {
    listen 80;
    server_name sito1.com www.sito1.com;
    root /var/www/sito1.com/public;
    index index.html index.htm;
    access_log /var/log/nginx/sito1.com.access.log;
    error_log /var/log/nginx/sito1.com.error.log;
    location / {
        try_files $uri $uri/ =404;
    }
}

listen 80 ascolta il traffico HTTP; server_name identifica il dominio; root indica la directory web; index specifica il file di default. try_files restituisce 404 se il file o la cartella richiesta non esiste. Per siti statici questa configurazione è sufficiente.

3. Attiva il sito

Per attivare la configurazione, crea il link simbolico: sudo ln -s /etc/nginx/sites-available/sito1.com /etc/nginx/sites-enabled/sito1.com. Meglio del copia-incolla: così lavori su un solo file, e le modifiche sono sempre aggiornate.

Se non vuoi che la pagina di default di Nginx venga mostrata, puoi disabilitare la configurazione default rimuovendo il link in /etc/nginx/sites-enabled/default. Prima, però, assicurati che il tuo server block funzioni.

4. Testa la configurazione e ricarica Nginx

Dopo ogni modifica, verifica la sintassi con sudo nginx -t. Se il test è OK, ricarica il servizio con sudo systemctl reload nginx (meglio di restart, mantiene attive le connessioni esistenti).

Se il test fallisce, l’errore indica il file e la riga: controlla punti e virgola mancanti, parentesi, path errati o server_name duplicati. Non ricaricare Nginx finché non hai risolto il problema.

Aggiungere altri siti: secondo e terzo block

La bellezza dell’hosting multi-sito è che, una volta impostato il primo, il processo diventa replicabile. Per sito2.com crei /var/www/sito2.com/public, il file di configurazione /etc/nginx/sites-available/sito2.com, cambi root e i log, attivi il link simbolico e testi.

Esempio di configurazione per il secondo sito:

server {
    listen 80;
    server_name sito2.com www.sito2.com;
    root /var/www/sito2.com/public;
    index index.html;
    access_log /var/log/nginx/sito2.com.access.log;
    error_log /var/log/nginx/sito2.com.error.log;
    location / {
        try_files $uri $uri/ =404;
    }
}

Usare log separati è utilissimo: se un sito ha molteplici errori 404 e un altro no, puoi individuare subito il problema. Anche analisi del traffico, attacchi bot, link rotti e problemi di performance sono monitorabili per singolo dominio.

SSL e configurazione HTTPS

Secondo gli standard SEO 2026, HTTPS è ormai imprescindibile per la fiducia dell’utente e la qualità tecnica. I browser segnalano i siti HTTP come non sicuri; per pagamenti, registrazioni, form o pannelli admin, SSL è obbligatorio. Ogni dominio deve avere il certificato giusto. Per le tue esigenze SSL, consulta la pagina certificati SSL su Hostragons.

Con Let’s Encrypt puoi generare certificati per ogni dominio tramite Certbot. Esempio: certbot --nginx -d sito1.com -d www.sito1.com rileva la configurazione e aggiunge automaticamente il block HTTPS. Ma dopo l’automatismo, controlla sempre la configurazione: redirect errati o blocchi duplicati possono causare problemi.

Di solito, il traffico sulla porta 80 viene reindirizzato in modo permanente (301) verso la 443. Scegli un indirizzo canonico (con o senza www) e indirizza tutte le varianti verso quello. Ad esempio, se preferisci https://sito1.com, reindirizza sia il traffico HTTP che HTTPS www verso la versione senza www. Questo riduce il rischio di contenuti duplicati.

Nginx server blocks per siti PHP e WordPress

Per siti HTML statici la configurazione è semplice, ma per WordPress, Laravel o PHP custom serve l’integrazione con PHP-FPM. Devi definire index.php e indirizzare le richieste PHP verso il socket corrispondente (es. /run/php/php8.3-fpm.sock su Ubuntu, versione variabile).

Esempio di server block PHP:

server {
    listen 80;
    server_name wordpress-site.com www.wordpress-site.com;
    root /var/www/wordpress-site.com/public;
    index index.php index.html;
    location / {
        try_files $uri $uri/ /index.php?$args;
    }
    location ~ \.php$ {
        include snippets/fastcgi-php.conf;
        fastcgi_pass unix:/run/php/php8.3-fpm.sock;
    }
}

Per WordPress, la regola try_files $uri $uri/ /index.php?$args è fondamentale per i permalink. Considera anche blocchi per xmlrpc.php, limitazione di wp-login.php, disabilitazione dell’esecuzione PHP in uploads per la sicurezza. Per molti WordPress sulla stessa VPS usa database e utenti separati, aggiorna regolarmente. Se cerchi alternative gestite, guarda Hosting WordPress.

Confronto: Nginx server blocks vs Apache VirtualHost

Nginx e Apache raggiungono lo stesso obiettivo con architetture diverse. Entrambi permettono hosting multi-sito, la scelta dipende dalle esigenze applicative e dalle abitudini di gestione.

Se la tua applicazione dipende molto da regole .htaccess, Apache è più comodo. Nginx è preferibile per traffico elevato, proxy inverso, caching e flussi di deployment moderni. In alcune infrastrutture puoi usare Nginx come reverse proxy e Apache come backend.

Best practice di sicurezza

Ospitare più siti sullo stesso server è vantaggioso per i costi, ma aumenta le responsabilità sulla sicurezza. Per evitare che un problema su un sito impatti gli altri, applica isolamento e principio del minimo privilegio.

• Crea database e utenti separati per ogni sito.
• Limita la root web alle sole directory public.
• Escludi dal web backup, .env, .git, file config e SQL.
• Rinnova regolarmente i certificati SSL e forza il redirect HTTPS.
• Usa UFW o firewall simile, apri solo le porte necessarie.
• Aggiorna Nginx e il sistema operativo regolarmente.
• Tieni log di accesso ed errore separati per ogni sito.
• Proteggi i pannelli admin con restrizioni IP o autenticazione aggiuntiva.
• Evita permessi 777.

Valuta l’aggiunta di header di sicurezza come X-Frame-Options, X-Content-Type-Options, Referrer-Policy e Content-Security-Policy dove opportuno. Testa sempre prima in staging, soprattutto Content-Security-Policy, che può bloccare script e CSS se configurata male. Per approfondimenti sulla sicurezza, consulta Sicurezza del sito web.

Ottimizzazione performance e SEO

I server blocks di Nginx influenzano anche la velocità e la qualità SEO. Redirect errati, scelte canonical sbagliate, compressione gzip/brotli assente, log troppo grandi o caching insufficiente rallentano il sito. Google premia siti veloci, sicuri e stabili.

Scegli una sola versione canonica per ogni dominio. Esegui redirect HTTP→HTTPS, www→non-www (o viceversa) in un solo passaggio. Evita catene di redirect come http://sito.com → http://www.sito.com → https://www.sito.com → https://sito.com: meglio un solo redirect 301 diretto.

Usa header cache-control per file statici (immagini, CSS, JS); per file che cambiano spesso, usa versionamento nel nome o query string. La compressione gzip riduce la banda su file HTML, CSS, JS, JSON. Per siti ad alto traffico, valuta microcache Nginx, FastCGI cache o CDN. Per CDN e accesso globale, consulta Che cos'è il CDN.

Gestione e monitoraggio dei log

La gestione dei log è fondamentale per risolvere problemi su siti multipli. Log separati mostrano chiaramente dove si verificano errori. access_log registra le richieste, error_log problemi di configurazione, permessi, file mancanti, errori upstream. Ad esempio, un errore 502 Bad Gateway spesso dipende da PHP-FPM o un servizio backend; 403 Forbidden da permessi o assenza del file index; 404 Not Found da path errato, regole rewrite o root sbagliato.

Per evitare che i log crescano senza limiti, configura logrotate. Per piccoli progetti basta una rotazione giornaliera o settimanale; per siti ad alto traffico usa raccolta centralizzata, metriche e alert. Un disco pieno impedisce a Nginx di scrivere log, blocca il database e rende i siti offline: imposta soglie di sicurezza sullo spazio disco.

Errori comuni e soluzioni rapide

Quando lavori con i server blocks di Nginx, alcuni errori sono frequenti. Conoscerli accelera il setup.

• Il dominio apre il sito sbagliato: controlla server_name e il block di default.
• 403 Forbidden: verifica root, permessi e presenza del file index.
• 404 Not Found: controlla il path root e la regola try_files.
• 502 Bad Gateway: assicurati che PHP-FPM sia attivo e il socket corretto.
• Certificato SSL errato: verifica server_name e file del certificato sul block 443.
• Loop di redirect: semplifica le regole di redirect HTTP-HTTPS e www.
• Nginx non si ricarica: correggi gli errori di sintassi indicati da nginx -t.

Gli admin esperti seguono una checklist: DNS corretto, configurazione Nginx attiva, root folder esistente, permessi giusti, test superato, log chiaro. Segui questi step per risolvere velocemente senza panico.

Checklist pratica per produzione

Prima di andare online, verifica ogni sito con questa lista. Per progetti clienti, documentare questi punti garantisce uno standard professionale.

• Il dominio punta all’IP corretto tramite record A o AAAA.
• Una sola versione (www o non-www) è canonica.
• Il traffico HTTP viene reindirizzato a HTTPS con redirect 301.
• Certificati SSL validi e rinnovo automatico attivo.
• Root e file di log separati per ogni sito.
• Configurazione Nginx validata con sudo nginx -t.
• Piano di backup definito e test di ripristino effettuato.
• Permessi file conformi al principio del minimo privilegio.
• Solo le porte necessarie aperte nel firewall.
• Log errori monitorati almeno 15 minuti dopo il go-live.

Sembra una lista semplice, ma in progetti reali riduce drasticamente il rischio di downtime. SSL, DNS e log sono spesso fonti di errori invisibili che questa checklist intercetta in anticipo.

Conclusioni

I server blocks di Nginx sono la soluzione fondamentale per ospitare più siti in modo ordinato, sicuro e performante su un unico server. Con una struttura delle directory corretta, configurazioni separate, regole di redirect chiare, uso di HTTPS, log distinti e test regolari, la gestione multi-sito diventa efficiente. Gli stessi principi valgono sia per piccoli portfolio che per progetti multi-cliente.

Se devi pubblicare un nuovo progetto, definisci prima dominio, risorse server e SSL; poi segui la checklist e configura Nginx passo dopo passo. Se cerchi una soluzione più gestibile, esplora Pacchetti di Hosting, server VPS e certificati SSL su Hostragons per scegliere il punto di partenza adatto al tuo progetto.

Domande frequenti

Quanti siti si possono ospitare con i server blocks di Nginx?

In teoria, puoi ospitare un gran numero di siti su un solo server Nginx; il limite dipende da CPU, RAM, spazio disco, traffico, carico database e capacità di PHP-FPM. Su siti statici a basso traffico puoi gestire decine di progetti; per WordPress o e-commerce ad alto traffico meglio limitare il numero.

Serve un certificato SSL separato per ogni sito?

Sì, ogni dominio o sottodominio pubblicato in HTTPS deve essere coperto dal certificato. Puoi usare certificati singoli, SAN o wildcard. L’importante è associare correttamente il file del certificato al dominio nel block 443 di Nginx.

Si possono pubblicare sottodomini con i server blocks?

Certo. Puoi definire server_name per sottodomini come blog.sito.com o panel.sito.com, puntando root o backend diversi. Dal lato DNS, crea record A o CNAME per il sottodominio.

Qual è la differenza tra sites-available e sites-enabled?

sites-available contiene tutte le configurazioni disponibili; sites-enabled quelle attive. Di norma, si crea un link simbolico da sites-enabled verso il file in sites-available. Così attivare o disattivare un sito è semplice e ordinato.

Perché viene mostrato il sito sbagliato?

Le cause più comuni sono DNS puntato all’IP errato, server_name sbagliato, block di default che intercetta la richiesta o block HTTPS con certificato errato. Controlla i record DNS, l’output di nginx -t, i link in sites-enabled e i log di accesso.