Comprensione dei Server Block di Nginx: Domande Comuni sulla Configurazione

Comprendere i server block di Nginx è uno dei modi più rapidi per rendere la configurazione di Nginx meno misteriosa. I server block decidono quale sito gestisce una richiesta, quali nomi di dominio corrispondono, quali file vengono serviti e dove va il traffico proxy.

Se ospiti più di un dominio, reindirizzi HTTP a HTTPS o esegui applicazioni dietro Nginx, i server block sono il punto di partenza per gran parte di questo instradamento.

Cos'è un Server Block di Nginx?

Un server block di Nginx è una sezione di configurazione che definisce come Nginx deve rispondere per una specifica combinazione di indirizzo, porta e nome host.

Un server block di base per un sito statico appare così:

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

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

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

Questo dice a Nginx di ascoltare sulla porta 80, abbinare le richieste per example.com e www.example.com, servire file dalla directory pubblica e restituire 404 quando un file non viene trovato.

Il nome "server block" è comune in Nginx. Gli utenti di Apache potrebbero conoscere un concetto simile come virtual host. Lo scopo è lo stesso: permettere a un server web di gestire più siti o applicazioni.

I server block sono solitamente memorizzati in /etc/nginx/sites-available/ e abilitati con collegamenti simbolici in /etc/nginx/sites-enabled/ su sistemi Debian e Ubuntu. Alcune distribuzioni usano invece /etc/nginx/conf.d/. La disposizione esatta è meno importante di sapere quali file sono inclusi da nginx.conf.

Come Sceglie Nginx il Server Block Giusto?

La selezione di Nginx avviene in fasi. Prima considera l'indirizzo IP e la porta dalla direttiva listen. Poi confronta il nome host della richiesta con server_name.

Se nessun nome host corrisponde, Nginx usa il server predefinito per quell'indirizzo e porta. Puoi contrassegnarne uno esplicitamente:

server {
    listen 80 default_server;
    server_name _;
    return 444;
}

Alcuni team usano un blocco predefinito come questo per scartare le richieste non corrispondenti. Altri restituiscono un semplice 404. La scelta migliore dipende dalle tue preferenze di logging e sicurezza.

Se stai ancora imparando, un predefinito 404 visibile può essere più facile da debuggare di return 444, perché 444 è una chiusura di connessione specifica di Nginx e può sembrare un problema di rete dal lato client. In produzione, alcuni team preferiscono la chiusura silenziosa per host casuali non corrispondenti. Entrambe le scelte vanno bene se il team le comprende.

I nomi esatti sono preferiti rispetto ai nomi con wildcard. Ad esempio, api.example.com è più specifico di *.example.com. I nomi server con espressioni regolari sono possibili, ma dovrebbero essere rari perché sono più difficili da leggere e risolvere.

Un errore comune è aggiungere un nuovo dominio al DNS ma dimenticare di aggiungerlo a server_name. La richiesta arriva al server, ma Nginx la invia al blocco predefinito. Dal punto di vista dell'utente, appare il sito sbagliato o la richiesta fallisce.

Un altro errore comune è creare due blocchi che rivendicano entrambi lo stesso listen e server_name. Nginx potrebbe avvisare di nomi server in conflitto e ignorarne uno. Testa sempre la configurazione dopo aver aggiunto un sito.

Usa questo quando il sito sbagliato risponde:

sudo nginx -T | grep -n "server_name"
curl -I -H 'Host: example.com' http://127.0.0.1/

nginx -T stampa la configurazione completa caricata, inclusi i file inclusi. Questo è spesso più veloce che aprire ogni file in sites-enabled.

Cosa Contiene un Server Block?

Un server block di solito contiene direttive per l'abbinamento del dominio, TLS, document root, logging, reindirizzamenti e uno o più blocchi location.

Per un proxy inverso, il blocco potrebbe apparire così:

server {
    listen 443 ssl;
    server_name app.example.com;

    ssl_certificate /etc/letsencrypt/live/app.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/app.example.com/privkey.pem;

    location / {
        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;
        proxy_pass http://127.0.0.1:3000;
    }
}

Qui, Nginx termina HTTPS e inoltra il traffico a un'applicazione locale sulla porta 3000. Questo è comune per applicazioni Node.js, Python, Ruby, Go e Java.

Se l'applicazione upstream ha bisogno di conoscere lo schema originale o l'IP del client, quelle righe proxy_set_header sono importanti. Senza di esse, l'app potrebbe pensare che ogni richiesta provenga da 127.0.0.1 su HTTP semplice. Questo può rompere reindirizzamenti, log di audit, limiti di velocità e URL di callback generati.

Usa percorsi di log chiari quando ospiti più siti:

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

Log separati rendono la risoluzione dei problemi molto più semplice. Quando ogni sito scrive in un unico log di accesso, ci vuole più tempo per individuare quale dominio sta fallendo.

Per un host trafficato, questo rende anche più facile la conservazione. Potresti volere log dettagliati per un'API durante un incidente e log più leggeri per un sito statico. Mantenere i file separati ti dà questa opzione senza dover modificare ogni server block contemporaneamente.

In Cosa Differiscono i Server Block dai Location Block?

I server block scelgono il sito. I location block scelgono cosa fare con i percorsi all'interno di quel sito.

Ad esempio:

server {
    server_name example.com;

    location /assets/ {
        expires 30d;
    }

    location /api/ {
        proxy_pass http://api_backend;
    }

    location / {
        try_files $uri $uri/ /index.html;
    }
}

Le richieste per /assets/logo.png ottengono la cache dei file statici. Le richieste per /api/users vanno a un backend upstream. Altre richieste ricadono sull'app frontend.

Questa suddivisione è importante. Se risponde il dominio sbagliato, guarda l'abbinamento del server block. Se risponde il dominio giusto ma il comportamento del percorso è sbagliato, guarda l'abbinamento del location block.

Questa distinzione fa risparmiare tempo. Una richiesta per api.example.com/users può fallire perché api.example.com ha abbinato il server block sbagliato, o perché /users ha abbinato il location block sbagliato all'interno del blocco giusto. Sono problemi diversi.

Per maggiori dettagli sull'instradamento dei percorsi, vedi Spiegazione dei location block di Nginx.

Come Dovrei Organizzare Più Siti?

Usa un file per sito o applicazione quando possibile. Dai a ogni file un nome che corrisponda al dominio o allo scopo:

/etc/nginx/sites-available/example.com
/etc/nginx/sites-available/api.example.com
/etc/nginx/sites-available/admin.example.com

Questo rende le revisioni più facili e riduce la possibilità di modificare il servizio sbagliato. Aiuta anche quando devi disabilitare rapidamente un sito.

Mantieni i frammenti condivisi piccoli e ovvi. Le impostazioni TLS, gli header proxy e gli header di sicurezza sono buoni candidati per gli include. Evita di nascondere comportamenti di instradamento principali in un file include generico, perché rende il debugging più difficile.

Una configurazione pratica potrebbe includere:

include snippets/proxy-headers.conf;
include snippets/security-headers.conf;

Usa gli include per ridurre la ripetizione, non per far comportare ogni sito in modo identico. Un pannello di amministrazione interno, un'API pubblica e un sito di marketing statico spesso necessitano di limiti e header diversi.

Prima di eliminare o rinominare un file di server block, controlla come viene incluso. Su layout in stile Debian, rimuovere il file da sites-available non fa nulla se un'altra copia esiste ancora in conf.d. D'altra parte, eliminare un collegamento simbolico in sites-enabled disabilita il sito senza eliminare il file sorgente.

ls -l /etc/nginx/sites-enabled/
sudo nginx -T | grep -n "include"

Questo controllo rapido previene il caso frustrante in cui modifichi il file dall'aspetto giusto e Nginx continua a usarne uno diverso.

Quando Chiedere Aiuto con Problemi di Server Block

Chiedi aiuto a un ingegnere DevOps o a uno specialista di Nginx quando le modifiche ai server block influenzano domini di produzione, certificati HTTPS, reindirizzamenti rivolti ai clienti o più applicazioni sullo stesso host. Piccoli errori possono inviare gli utenti all'app sbagliata o rompere il rinnovo dei certificati.

Dovresti anche chiedere aiuto se Nginx continua a servire il sito sbagliato dopo che pensi che la configurazione sia corretta. Il problema potrebbe coinvolgere DNS, IPv6, un bilanciatore di carico, una CDN o un file include che non hai notato.

I server block sono la mappa che Nginx usa per instradare il traffico a livello di dominio. Mantienili specifici, testa dopo ogni modifica, usa log separati e separa l'abbinamento del dominio dall'instradamento dei percorsi nel tuo modello mentale. Una volta che questo è chiaro, la maggior parte delle domande sulla configurazione di Nginx diventa molto più facile da rispondere.