Nginx Server Blocks : héberger plusieurs domaines sur un VPS

Un seul VPS peut servir des dizaines de sites. Nginx utilise les server blocks pour décider quel site servir selon le nom de domaine présent dans la requête. Ce guide couvre la configuration complète : deux domaines configurés de zéro, valeurs par défaut sécurisées, journaux par site, et vérification à chaque étape.

Ce tutoriel cible Debian 12 et Ubuntu 24.04. Les deux utilisent le même pattern sites-available/sites-enabled. Les commandes fonctionnent de manière identique sur les deux OS.

Qu'est-ce qu'un server block Nginx ?

Un server block est un bloc de configuration dans Nginx qui définit comment les requêtes pour un domaine spécifique sont traitées. C'est l'équivalent Nginx des virtual hosts d'Apache. Chaque server block utilise la directive listen pour se lier à un port et la directive server_name pour faire correspondre le nom de domaine depuis l'en-tête Host de la requête. Vous pouvez avoir autant de server blocks que nécessaire, tous partageant le port 80 ou 443.

Prérequis

Avant de commencer, il vous faut :

• Nginx installé et en cours d'exécution
• Deux noms de domaine avec des enregistrements DNS A pointant vers l'IP de votre serveur
• Un pare-feu autorisant les ports 80 et 443
• Un accès SSH en tant qu'utilisateur non-root avec sudo

Vérifiez que Nginx est en cours d'exécution :

sudo systemctl status nginx

Vous devriez voir active (running) dans la sortie. Sinon, démarrez-le et activez-le :

sudo systemctl enable --now nginx

Le flag enable fait démarrer Nginx automatiquement après les redémarrages. Le flag --now le démarre immédiatement.

Vérifiez que vos enregistrements DNS résolvent vers votre serveur. Remplacez les domaines par les vôtres tout au long de ce guide :

dig +short site-one.com
dig +short site-two.com

Les deux doivent retourner l'adresse IP publique de votre serveur.

Comment créer un server block pour un nouveau domaine ?

Le processus comporte trois parties : créer le répertoire racine des documents, définir les permissions, et écrire le fichier de configuration du server block. Nous allons configurer deux domaines : site-one.com et site-two.com.

Quelle structure de répertoires utiliser ?

Créez une racine de documents séparée pour chaque site sous /var/www/ :

sudo mkdir -p /var/www/site-one.com/html
sudo mkdir -p /var/www/site-two.com/html

Créez une page de test pour chaque site afin de vérifier quel domaine sert quel contenu :

echo '<h1>Site One</h1>' | sudo tee /var/www/site-one.com/html/index.html
echo '<h1>Site Two</h1>' | sudo tee /var/www/site-two.com/html/index.html

Quelles permissions faut-il pour la racine web ?

Nginx exécute ses processus worker en tant qu'utilisateur www-data. Les répertoires racine web doivent être lisibles par cet utilisateur.

sudo chown -R www-data:www-data /var/www/site-one.com
sudo chown -R www-data:www-data /var/www/site-two.com

Définissez les permissions à 755 (le propriétaire peut lire/écrire/exécuter, le groupe et les autres peuvent lire et traverser) :

sudo chmod -R 755 /var/www/site-one.com
sudo chmod -R 755 /var/www/site-two.com

Vérifiez la propriété et les permissions :

ls -la /var/www/

Sortie attendue :

drwxr-xr-x  2 www-data www-data 4096 Mar 19 10:00 site-one.com
drwxr-xr-x  2 www-data www-data 4096 Mar 19 10:00 site-two.com

Pourquoi www-data et pas votre utilisateur ? En production, l'utilisateur du serveur web doit posséder les fichiers statiques. Si votre application écrit des fichiers (uploads, caches), l'utilisateur du serveur web a besoin d'un accès en écriture. Utiliser votre utilisateur personnel ouvre un chemin d'une vulnérabilité web vers votre compte SSH.

Créer les fichiers de configuration des server blocks

Nginx sur Debian et Ubuntu utilise un pattern à deux répertoires : les fichiers de configuration résident dans /etc/nginx/sites-available/ et sont activés en créant des liens symboliques vers /etc/nginx/sites-enabled/. Cela vous permet de désactiver un site sans supprimer sa configuration.

Créez le server block pour le premier domaine :

sudo nano /etc/nginx/sites-available/site-one.com

server {
    listen 80;
    listen [::]:80;

    server_name site-one.com www.site-one.com;

    root /var/www/site-one.com/html;
    index index.html;

    access_log /var/log/nginx/site-one.com.access.log;
    error_log /var/log/nginx/site-one.com.error.log;

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

Ce que fait chaque directive :

• listen 80 et listen [::]:80 se lient au port 80 en IPv4 et IPv6.
• server_name liste les noms de domaine que ce bloc gère. Incluez les variantes nues et www.
• root pointe vers la racine des documents pour ce site.
• access_log et error_log écrivent des fichiers de journaux par site. Sans eux, tous les sites partagent /var/log/nginx/access.log, ce qui rend le débogage pénible.
• try_files sert le fichier demandé, essaie ensuite en tant que répertoire, puis retourne 404.

Créez le second server block :

sudo nano /etc/nginx/sites-available/site-two.com

server {
    listen 80;
    listen [::]:80;

    server_name site-two.com www.site-two.com;

    root /var/www/site-two.com/html;
    index index.html;

    access_log /var/log/nginx/site-two.com.access.log;
    error_log /var/log/nginx/site-two.com.error.log;

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

Comment activer et désactiver des server blocks ?

Les server blocks dans sites-available/ sont inactifs jusqu'à ce qu'ils soient liés symboliquement dans sites-enabled/.

Activer un site

Créez des liens symboliques pour les deux domaines :

sudo ln -s /etc/nginx/sites-available/site-one.com /etc/nginx/sites-enabled/
sudo ln -s /etc/nginx/sites-available/site-two.com /etc/nginx/sites-enabled/

Supprimez le server block par défaut fourni avec Nginx. Il entre en conflit avec vos nouveaux blocs et affiche la page « Welcome to Nginx » :

sudo rm /etc/nginx/sites-enabled/default

Cela ne supprime que le lien symbolique. Le fichier original reste dans sites-available/ au cas où vous en auriez besoin plus tard.

Tester la configuration avant d'appliquer

Testez toujours la configuration Nginx avant de recharger. Une erreur de syntaxe dans un fichier met hors service tous les sites :

sudo nginx -t

Sortie attendue :

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

Si vous avez besoin de voir la configuration fusionnée complète (tous les includes résolus en une seule sortie), utilisez :

sudo nginx -T

C'est le meilleur outil pour déboguer les problèmes de server blocks. Il montre exactement ce que Nginx va charger, y compris l'ordre des server blocks.

Recharger, pas redémarrer

Appliquez la nouvelle configuration :

sudo systemctl reload nginx

Pourquoi reload plutôt que restart ? Un reload envoie un signal à Nginx pour relire ses fichiers de configuration. Les connexions existantes finissent leur traitement normalement. Un restart tue le processus et en démarre un nouveau, interrompant toutes les connexions actives. En production, rechargez toujours.

Vérifiez que le rechargement a fonctionné :

sudo systemctl status nginx

Regardez bien : cherchez active (running) et vérifiez le timestamp sur la ligne « Main PID ». Il ne doit pas avoir changé (confirmant un reload, pas un restart).

Désactiver un site

Pour mettre un site hors ligne sans supprimer sa configuration :

sudo rm /etc/nginx/sites-enabled/site-two.com
sudo nginx -t && sudo systemctl reload nginx

Le fichier de configuration reste dans sites-available/. Réactivez-le à tout moment en recréant le lien symbolique.

Comment vérifier que vos server blocks fonctionnent ?

N'ouvrez pas un navigateur. Sur un VPS headless, utilisez curl avec l'en-tête Host pour simuler des requêtes depuis chaque domaine :

curl -H "Host: site-one.com" http://localhost

Sortie attendue :

<h1>Site One</h1>

curl -H "Host: site-two.com" http://localhost

Sortie attendue :

<h1>Site Two</h1>

Cela fonctionne même avant la propagation DNS, car vous indiquez directement à Nginx quel domaine vous voulez via l'en-tête Host.

Une fois le DNS propagé, testez depuis votre machine locale (pas le serveur) :

curl http://site-one.com
curl http://site-two.com

Chacun doit retourner la page de test correcte.

Comment Nginx décide-t-il quel server block gère une requête ?

Nginx fait correspondre les requêtes entrantes aux server blocks dans un ordre spécifique. Quand une requête arrive, Nginx filtre d'abord les server blocks par la directive listen (IP et port), puis fait correspondre l'en-tête Host aux valeurs server_name.

Quel est l'ordre de correspondance de server_name ?

L'ordre de correspondance est fixe et ne peut pas être modifié par l'ordre des fichiers de configuration :

Priorité	Type de pattern	Exemple	Quand utilisé
1 (plus haute)	Nom exact	site-one.com	Toujours testé en premier. Le plus rapide (table de hachage).
2	Wildcard préfixe le plus long	*.site-one.com	Correspond à www.site-one.com, api.site-one.com
3	Wildcard suffixe le plus long	mail.*	Correspond à mail.site-one.com, mail.site-two.com
4	Première regex correspondante	~^www\d+\.example\.com$	Évaluée dans l'ordre des fichiers de config. La première correspondance gagne.
5 (plus basse)	default_server	N/A	Fallback quand rien d'autre ne correspond.

Points clés :

• Les noms exacts sont toujours vérifiés en premier, peu importe où le server block apparaît dans la configuration.
• Les noms avec wildcard ne peuvent avoir le * qu'au début ou à la fin, sur une limite de point. w*.example.com est invalide.
• Les patterns regex commencent par ~ et sont testés dans l'ordre où ils apparaissent dans les fichiers de configuration. La première correspondance gagne. À utiliser avec parcimonie car ce sont les plus lents.
• Si rien ne correspond et qu'aucun default_server n'est défini, Nginx utilise le premier server block dans l'ordre des fichiers comme défaut. C'est une source fréquente de confusion.

Que fait la directive default_server ?

Le paramètre default_server sur la directive listen indique à Nginx quel server block gère les requêtes quand aucun server_name ne correspond. Sans lui, Nginx choisit silencieusement le premier server block chargé pour ce port. Cela signifie qu'un domaine mal configuré ou un bot qui scanne votre IP se verra servir l'un de vos vrais sites.

Créez un server block catch-all qui rejette les requêtes sans correspondance :

sudo nano /etc/nginx/sites-available/00-catch-all

server {
    listen 80 default_server;
    listen [::]:80 default_server;

    server_name _;

    return 444;
}

Ce que fait ce bloc :

• default_server marque ce bloc comme fallback pour le port 80.
• server_name _ est une convention pour « aucun nom valide ». Le tiret bas n'est pas spécial pour Nginx ; il ne correspond simplement jamais à un vrai hostname.
• return 444 est un code Nginx non-standard qui ferme la connexion sans envoyer de réponse. Les bots qui scannent votre IP ne reçoivent rien. Ni en-têtes, ni corps, ni informations sur le logiciel que vous utilisez.

Activez et appliquez :

sudo ln -s /etc/nginx/sites-available/00-catch-all /etc/nginx/sites-enabled/
sudo nginx -t && sudo systemctl reload nginx

Le nom de fichier commence par 00- pour qu'il apparaisse en premier dans les listes de répertoires. Cela n'a aucun effet sur le comportement de Nginx (c'est la directive default_server qui contrôle la sélection, pas l'ordre des fichiers), mais cela facilite la lecture de la configuration pour les humains.

Testez le catch-all en demandant un domaine qui ne correspond à aucun server block :

curl -v -H "Host: not-my-domain.com" http://localhost

Vous devriez voir Empty reply from server car Nginx a fermé la connexion sans réponse.

Comment configurer les journaux par site ?

Chaque server block de ce guide inclut déjà des directives de journalisation par site. Les journaux par site vous permettent de déboguer un site sans trier le trafic de tous vos autres domaines. Les chemins des journaux sont définis dans chaque server block :

access_log /var/log/nginx/site-one.com.access.log;
error_log /var/log/nginx/site-one.com.error.log;

Suivez les journaux en temps réel :

sudo tail -f /var/log/nginx/site-one.com.access.log

Ou utilisez journalctl pour les journaux du processus principal de Nginx (erreurs de démarrage, échecs de rechargement) :

journalctl -u nginx -f

Nginx gère la rotation des journaux automatiquement via /etc/logrotate.d/nginx. La politique par défaut effectue une rotation quotidienne et conserve 14 jours. Aucune configuration supplémentaire n'est nécessaire.

Quels sont les problèmes courants et leurs solutions ?

Symptôme	Cause	Solution
La page « Welcome to Nginx » s'affiche pour tous les domaines	Le lien symbolique default est encore dans sites-enabled/	sudo rm /etc/nginx/sites-enabled/default && sudo systemctl reload nginx
Mauvais site servi pour un domaine	server_name en doublon entre les blocs, ou pas de correspondance exacte trouvée	Exécutez `sudo nginx -T
Erreur could not build server_names_hash	Noms de domaine trop longs pour le bucket de hachage par défaut	Ajoutez server_names_hash_bucket_size 128; dans le bloc http {} dans /etc/nginx/nginx.conf
Les modifications ne prennent pas effet après édition	Rechargement oublié	sudo nginx -t && sudo systemctl reload nginx
bind() to 0.0.0.0:80 failed	Un autre processus (Apache, ancien Nginx) utilise le port 80	`sudo ss -tlnp
Lien symbolique créé mais le site ne charge pas	Le lien symbolique pointe vers un chemin incorrect (relatif au lieu d'absolu)	Supprimez et recréez : sudo ln -sf /etc/nginx/sites-available/site-one.com /etc/nginx/sites-enabled/

Débogage avec nginx -T

Quand un site ne se comporte pas comme prévu, affichez la configuration fusionnée complète :

sudo nginx -T 2>&1 | grep -A 5 "server_name"

Cela montre chaque server block avec sa valeur server_name, vous permettant de voir exactement ce que Nginx a chargé et dans quel ordre. Toutes les directives include sont résolues, donc vous voyez la vraie configuration, pas seulement les fichiers sur le disque.

Prochaines étapes

Vos server blocks servent maintenant plusieurs domaines en HTTP. La prochaine étape est d'ajouter des certificats TLS pour que ces sites soient servis en HTTPS.

Pour une vue d'ensemble de la gestion de Nginx sur un VPS, consultez le guide parent.

---

Copyright 2026 Virtua.Cloud. Tous droits reserves. Ce contenu est une creation originale de l'equipe Virtua.Cloud. Toute reproduction, republication ou redistribution sans autorisation ecrite est interdite.