Comprendre les blocs serveur Nginx : questions courantes sur la configuration

Comprendre les blocs serveur Nginx est l'un des moyens les plus rapides de rendre votre configuration Nginx moins mystérieuse. Les blocs serveur déterminent quel site traite une requête, quels noms de domaine correspondent, quels fichiers sont servis et où va le trafic proxy.

Si vous hébergez plus d'un domaine, redirigez HTTP vers HTTPS ou exécutez des applications derrière Nginx, les blocs serveur sont l'endroit où commence la majeure partie de ce routage.

Qu'est-ce qu'un bloc serveur Nginx ?

Un bloc serveur Nginx est une section de configuration qui définit comment Nginx doit répondre pour une combinaison spécifique d'adresse, de port et de nom d'hôte.

Un bloc serveur de site statique de base ressemble à ceci :

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;
    }
}

Cela indique à Nginx d'écouter sur le port 80, de faire correspondre les requêtes pour example.com et www.example.com, de servir les fichiers du répertoire public et de renvoyer une erreur 404 lorsqu'un fichier n'est pas trouvé.

Le nom "bloc serveur" est courant dans Nginx. Les utilisateurs d'Apache peuvent connaître une idée similaire sous le nom d'hôte virtuel. Le but est le même : permettre à un serveur web de gérer plusieurs sites ou applications.

Les blocs serveur sont généralement stockés dans /etc/nginx/sites-available/ et activés avec des liens symboliques dans /etc/nginx/sites-enabled/ sur les systèmes Debian et Ubuntu. Certaines distributions utilisent /etc/nginx/conf.d/ à la place. La disposition exacte est moins importante que de savoir quels fichiers sont inclus par nginx.conf.

Comment Nginx choisit-il le bon bloc serveur ?

La sélection Nginx se fait par étapes. D'abord, il considère l'adresse IP et le port de la directive listen. Ensuite, il compare le nom d'hôte de la requête à server_name.

Si aucun nom d'hôte ne correspond, Nginx utilise le serveur par défaut pour cette adresse et ce port. Vous pouvez en marquer un explicitement :

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

Certaines équipes utilisent un bloc par défaut comme celui-ci pour abandonner les requêtes non correspondantes. D'autres renvoient une simple 404. Le meilleur choix dépend de vos préférences en matière de journalisation et de sécurité.

Si vous apprenez encore, une valeur par défaut 404 visible peut être plus facile à déboguer que return 444, car 444 est une fermeture de connexion spécifique à Nginx et peut ressembler à un problème réseau du côté client. En production, certaines équipes préfèrent la fermeture silencieuse pour les hôtes non correspondants aléatoires. Les deux choix sont acceptables si l'équipe les comprend.

Les noms exacts sont préférés aux noms avec caractères génériques. Par exemple, api.example.com est plus spécifique que *.example.com. Les noms de serveur avec expressions régulières sont possibles, mais ils devraient être rares car ils sont plus difficiles à lire et à dépanner.

Une erreur courante consiste à ajouter un nouveau domaine au DNS mais à oublier de l'ajouter à server_name. La requête atteint le serveur, mais Nginx l'envoie au bloc par défaut. Du point de vue de l'utilisateur, le mauvais site apparaît ou la requête échoue.

Une autre erreur courante consiste à créer deux blocs qui revendiquent tous deux le même listen et server_name. Nginx peut avertir des noms de serveur conflictuels et en ignorer un. Testez toujours la configuration après avoir ajouté un site.

Utilisez ceci lorsque le mauvais site répond :

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

nginx -T affiche la configuration complète chargée, y compris les fichiers inclus. C'est souvent plus rapide que d'ouvrir chaque fichier dans sites-enabled.

Que contient un bloc serveur ?

Un bloc serveur contient généralement des directives pour la correspondance de domaine, TLS, le document root, la journalisation, les redirections et un ou plusieurs blocs location.

Pour un proxy inverse, le bloc peut ressembler à ceci :

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;
    }
}

Ici, Nginx termine HTTPS et transmet le trafic à une application locale sur le port 3000. C'est courant pour les applications Node.js, Python, Ruby, Go et Java.

Si l'application en amont a besoin de connaître le schéma d'origine ou l'IP du client, ces lignes proxy_set_header sont importantes. Sans elles, l'application peut penser que chaque requête provient de 127.0.0.1 via HTTP simple. Cela peut casser les redirections, les journaux d'audit, les limites de débit et les URL de rappel générées.

Utilisez des chemins de journal clairs lors de l'hébergement de plusieurs sites :

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

Des journaux séparés facilitent grandement le dépannage. Lorsque chaque site écrit dans un seul journal d'accès, il faut plus de temps pour repérer quel domaine échoue.

Pour un hôte occupé, cela facilite également la conservation. Vous pouvez vouloir des journaux détaillés pour une API lors d'un incident et une journalisation plus légère pour un site statique. Garder les fichiers séparés vous donne cette option sans modifier chaque bloc serveur à la fois.

En quoi les blocs serveur sont-ils différents des blocs location ?

Les blocs serveur choisissent le site. Les blocs location choisissent quoi faire avec les chemins à l'intérieur de ce site.

Par exemple :

server {
    server_name example.com;

    location /assets/ {
        expires 30d;
    }

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

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

Les requêtes pour /assets/logo.png obtiennent une mise en cache de fichiers statiques. Les requêtes pour /api/users vont à un backend en amont. Les autres requêtes sont transmises à l'application frontend.

Cette séparation est importante. Si le mauvais domaine répond, regardez la correspondance du bloc serveur. Si le bon domaine répond mais que le comportement du mauvais chemin se produit, regardez la correspondance du bloc location.

Cette distinction fait gagner du temps. Une requête pour api.example.com/users peut échouer parce que api.example.com a correspondu au mauvais bloc serveur, ou parce que /users a correspondu au mauvais emplacement à l'intérieur du bon bloc. Ce sont des problèmes différents.

Pour plus de détails sur le routage des chemins, voir Explication des blocs location Nginx.

Comment organiser plusieurs sites ?

Utilisez un fichier par site ou application lorsque c'est possible. Donnez à chaque fichier un nom qui correspond au domaine ou à l'objectif :

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

Cela facilite les révisions et réduit le risque de modifier le mauvais service. Cela aide également lorsque vous devez désactiver un site rapidement.

Gardez les snippets partagés petits et évidents. Les paramètres TLS, les en-têtes proxy et les en-têtes de sécurité sont de bons candidats pour les inclusions. Évitez de cacher un comportement de routage majeur dans un fichier d'inclusion générique, car cela rend le débogage plus difficile.

Une configuration pratique pourrait inclure :

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

Utilisez les inclusions pour réduire la répétition, pas pour rendre chaque site identique. Un panneau d'administration interne, une API publique et un site marketing statique ont souvent besoin de limites et d'en-têtes différents.

Avant de supprimer ou renommer un fichier de bloc serveur, vérifiez comment il est inclus. Dans les dispositions de style Debian, supprimer le fichier de sites-available ne fait rien si une autre copie existe encore dans conf.d. D'un autre côté, supprimer un lien symbolique dans sites-enabled désactive le site sans supprimer le fichier source.

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

Cette vérification rapide évite le cas frustrant où vous modifiez le fichier qui semble correct et Nginx continue d'en utiliser un autre.

Quand demander de l'aide pour les problèmes de blocs serveur

Demandez l'aide d'un ingénieur DevOps ou d'un spécialiste Nginx lorsque les modifications des blocs serveur affectent les domaines de production, les certificats HTTPS, les redirections côté client ou plusieurs applications sur le même hôte. De petites erreurs peuvent envoyer les utilisateurs vers la mauvaise application ou casser le renouvellement des certificats.

Vous devriez également demander de l'aide si Nginx continue de servir le mauvais site après avoir pensé que la configuration est correcte. Le problème peut impliquer le DNS, IPv6, un équilibreur de charge, un CDN ou un fichier d'inclusion que vous n'avez pas remarqué.

Les blocs serveur sont la carte que Nginx utilise pour router le trafic au niveau du domaine. Gardez-les spécifiques, testez après chaque modification, utilisez des journaux séparés et séparez la correspondance de domaine du routage de chemin dans votre modèle mental. Une fois que cela est clair, la plupart des questions de configuration Nginx deviennent beaucoup plus faciles à répondre.