Héberger plusieurs sites avec Nginx

Un VPS peut héberger plusieurs noms de domaine sans conteneur ni machine supplémentaire. Nginx distingue les sites grâce à l'en-tête Host de la requête : chaque domaine reçoit son propre bloc server, sa racine et ses journaux. Voici une configuration lisible pour deux sites, puis les contrôles qui évitent d'afficher le mauvais contenu.

Un bloc server par site

Créez une racine distincte par site. Des fichiers statiques suffisent pour l'exemple ; une application PHP ou Node.js se branche ensuite sur la même racine ou derrière un proxy.

sudo mkdir -p /var/www/site-a.fr /var/www/site-b.fr
sudo chown -R deploy:www-data /var/www/site-a.fr /var/www/site-b.fr
sudo chmod 750 /var/www/site-a.fr /var/www/site-b.fr

Placez un index.html dans chaque dossier, puis créez /etc/nginx/sites-available/site-a.fr.conf :

server {
    listen 80;
    listen [::]:80;
    server_name site-a.fr www.site-a.fr;

    root /var/www/site-a.fr;
    index index.html;

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

    access_log /var/log/nginx/site-a.fr.access.log;
    error_log  /var/log/nginx/site-a.fr.error.log;
}

listen [::]:80 est indispensable si vous publiez l'IPv6 ; sans lui, Nginx n'écoute que sur IPv4. server_name accepte plusieurs noms, mais le premier bloc qui correspond gagne. try_files renvoie un 404 propre au lieu de lister le dossier.

Activer le site et recharger

Le paquet Debian lit sites-enabled, pas sites-available. Le lien symbolique active le site sans dupliquer le fichier.

sudo ln -s /etc/nginx/sites-available/site-a.fr.conf /etc/nginx/sites-enabled/
sudo nginx -t
sudo systemctl reload nginx

nginx -t valide la syntaxe et les chemins avant tout rechargement ; ne sautez pas cette étape. reload applique la configuration sans couper les connexions en cours. Répétez l'opération pour le second site.

Pour qu'un domaine inconnu ne tombe pas sur le premier site, supprimez le lien /etc/nginx/sites-enabled/default du paquet, puis gardez un bloc par défaut explicite :

server {
    listen 80 default_server;
    listen [::]:80 default_server;
    server_name _;
    return 444;
}

Le code 444 ferme la connexion sans réponse. Si vous préférez conserver le site par défaut, adaptez-le plutôt que d'ajouter un second default_server, que Nginx refuserait.

Vérifier avant d'ouvrir au public

Testez localement avec l'en-tête Host, puis en IPv6 et depuis l'extérieur :

curl -H "Host: site-a.fr" http://127.0.0.1/
curl -6 -H "Host: site-a.fr" http://[::1]/
dig +short AAAA site-a.fr

Comparez les réponses et consultez /var/log/nginx/site-a.fr.access.log. Un 403 indique presque toujours des permissions ou un index absent ; un 404, une racine mal orthographiée. Vérifiez que www-data peut traverser chaque dossier parent avec namei -l /var/www/site-a.fr/index.html.

Erreurs fréquentes

• Deux default_server sur le même port : Nginx refuse de démarrer.
• Un server_name contenant https:// ou un slash : ce n'est pas une URL, seulement le nom.
• Le DNS pointe encore ailleurs : testez avec curl --resolve site-a.fr:80:VOTRE_IPV6.
• Après édition, systemctl restart masque une erreur de syntaxe ; préférez nginx -t puis reload.

Quand les deux domaines répondent avec leur contenu respectif en IPv4 et en IPv6, ajoutez HTTPS site par site. Gardez une copie de /etc/nginx avant la prochaine modification.