Héberger Plusieurs Sites sur un Serveur Nginx grâce aux Blocs Serveur (Virtual Hosts)

Les blocs serveur Nginx (server blocks), aussi appelés "virtual hosts", permettent d’héberger plusieurs sites web ou domaines sur une même instance Nginx, chacun avec sa configuration dédiée. Par exemple, vous pouvez servir example.com, blog.example.com et second-site.com sur un seul VPS, avec des dossiers racine distincts, des fichiers de logs séparés, des certificats SSL uniques et des paramètres PHP adaptés à chaque projet. En résumé : créez un dossier par site, configurez les enregistrements DNS du domaine vers l’IP du serveur, rédigez un bloc serveur séparé dans /etc/nginx/sites-available, liez-le dans sites-enabled, vérifiez la configuration et rechargez le service Nginx.

Ce guide vous accompagne dans la mise en place de l’hébergement multi-sites via Nginx, adapté à un environnement de production. L’objectif n’est pas seulement de rendre la solution fonctionnelle, mais aussi de la rendre facile à gérer, sécurisée, performante, sauvegardable et évolutive. Nous partagerons des conseils pratiques pour les agences, développeurs, e-commerçants, entreprises multi-marques et administrateurs système qui gèrent plusieurs projets sur un seul serveur. Si vous n’avez pas encore de serveur, consultez les pages serveur VPS pour le choix des ressources et Enregistrement de domaine pour la gestion des noms de domaine.

Qu’est-ce qu’un Bloc Serveur Nginx ?

Un bloc serveur Nginx est une section de la configuration, définie par un bloc server, qui indique à Nginx comment traiter les requêtes HTTP ou HTTPS en fonction du nom de domaine demandé. Le principe est similaire à celui des VirtualHost sur Apache. Quand un visiteur saisit un nom de domaine dans son navigateur, le DNS résout ce nom vers l’IP du serveur, puis Nginx examine l’en-tête Host et active le bloc serveur dont le server_name correspond.

Grâce à ce mécanisme, un même serveur physique ou VPS peut héberger plusieurs sites web sur une seule IP. Pour chaque site, il est possible de définir un dossier racine, des logs d’accès et d’erreur, des règles de redirection, des certificats SSL, des stratégies de cache et des règles de sécurité. Par exemple, votre site institutionnel peut résider dans /var/www/entreprise/public, votre blog dans /var/www/blog/public, et un environnement de test dans /var/www/staging/public.

Nginx excelle dans ce modèle grâce à son architecture événementielle, qui gère de nombreuses connexions simultanées avec peu de ressources. C’est pourquoi il est utilisé sur l’hébergement mutualisé, les VPS, les serveurs cloud et les infrastructures à fort trafic. Pour que l’hébergement multi-sites fonctionne correctement, chaque détail doit être soigneusement planifié : droits de fichiers, configuration DNS, installation SSL, séparation des logs, etc.

Quand Utiliser les Blocs Serveur Nginx ?

Les blocs serveur sont indispensables lorsque vous souhaitez gérer plusieurs sites ou applications sur un même serveur. Cela peut aller de deux sites institutionnels à des dizaines de projets clients, sous-domaines ou microservices. Le point central : chaque projet doit être isolé logiquement.

• Vous voulez publier plusieurs domaines sur un seul VPS.
• Vous souhaitez rediriger www et non-www vers une version canonique.
• Vous souhaitez associer différents sous-domaines à des dossiers ou applications distincts.
• Vous voulez définir des certificats SSL et politiques de sécurité propres à chaque site.
• Vous voulez suivre les logs de chaque projet séparément.
• Vous souhaitez héberger sur le même serveur des applications Laravel, WordPress, HTML statique, Node.js, etc.

Par exemple, une agence digitale peut héberger 8 sites institutionnels à faible trafic sur un seul VPS de 4 Go de RAM. Il faudra toutefois calculer le trafic, l’utilisation disque, les processus PHP, la charge base de données et la fréquence des sauvegardes pour chaque projet. Si vos sites reçoivent beaucoup de visites ou nécessitent une isolation stricte, optez pour un VPS plus puissant, un serveur cloud ou un hébergement managé. Comparez à ce sujet Hébergement Web et Hébergement Professionnel.

Prérequis Avant de Commencer

Ce tutoriel part du principe que vous utilisez un serveur Linux Ubuntu ou Debian. Les commandes peuvent varier légèrement selon la distribution, mais le principe reste le même. Avant toute opération en production, effectuez une sauvegarde. Une mauvaise configuration Nginx peut rendre tous vos sites inaccessibles temporairement.

Préparatifs techniques nécessaires

• Compte utilisateur Linux avec droits root ou sudo.
• Nginx installé et en fonctionnement.
• Au moins un domaine pointant vers l’IP du serveur.
• Ports 80 et 443 ouverts dans le pare-feu.
• Arborescence de dossiers claire pour les fichiers de site.
• Certificat SSL valide ou Let’s Encrypt gratuit.
• PHP-FPM installé si vous hébergez des applications PHP.

Côté DNS, l’enregistrement A pointe le domaine principal vers l’IPv4, AAAA vers l’IPv6 si applicable. Les sous-domaines comme www utilisent un CNAME ou A. La propagation DNS prend de quelques minutes à 24 h. Préparez d’abord vos enregistrements DNS, puis passez à la configuration des blocs serveur Nginx pour accélérer le processus.

Structure de Dossiers Recommandée

L’erreur la plus fréquente lors de l’hébergement multi-sites est de mélanger tous les fichiers dans un seul dossier. Cela semble pratique au début, mais complique la maintenance, la sauvegarde et le débogage. L’idéal est d’utiliser un dossier parent par domaine, avec des sous-dossiers public, logs, backups, etc.

Par exemple : /var/www/site1.com/public, /var/www/site1.com/logs, /var/www/site2.com/public. Le paramètre root de Nginx doit pointer sur le dossier public. Ainsi, les fichiers d’application, variables d’environnement (.env), sauvegardes, etc., ne seront pas accessibles directement depuis le web.

Pour vérifier rapidement quel bloc serveur fonctionne, placez un fichier index.html distinct dans chaque dossier public avec le nom du site. En production, l’utilisateur du dossier est souvent www-data ou un utilisateur de déploiement. Les permissions classiques sont 755 pour les dossiers, 644 pour les fichiers. Pour WordPress, les dossiers d’uploads nécessitent des réglages particuliers.

Créer un Bloc Serveur Nginx : Étapes

Les étapes suivantes illustrent la procédure pour site1.com. Répétez ce processus pour chaque nouveau site. L’essentiel : un server_name, un root et des fichiers de log distincts par site.

1. Créez le dossier du site

Commencez par créer le dossier qui accueillera les fichiers web : sudo mkdir -p /var/www/site1.com/public. Ajoutez un fichier index.html dans /var/www/site1.com/public avec un message du type "Ceci est la page test de site1.com" pour le distinguer.

Pour définir le propriétaire des fichiers : sudo chown -R www-data:www-data /var/www/site1.com. Si vous déployez avec un autre utilisateur, ajustez le groupe en conséquence. Évitez absolument les permissions 777 qui exposent vos dossiers à des attaques.

2. Créez le fichier de bloc serveur

La pratique courante consiste à stocker les configurations non activées dans /etc/nginx/sites-available, puis à les activer via un lien symbolique dans /etc/nginx/sites-enabled. Ex : /etc/nginx/sites-available/site1.com.

Un bloc serveur HTTP de base :

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

listen 80 écoute le trafic HTTP, server_name définit les domaines associés, root indique le dossier des fichiers web, index précise le fichier par défaut. try_files retourne une erreur 404 si le fichier ou dossier n’existe pas. Pour un site statique, cette configuration suffit.

3. Activez le site

Pour activer la configuration : sudo ln -s /etc/nginx/sites-available/site1.com /etc/nginx/sites-enabled/site1.com. Cette méthode est préférable à la copie, car elle garde une gestion centralisée des fichiers. Toute modification est reflétée sur le lien.

Si vous ne voulez pas que la page par défaut de Nginx apparaisse avant vos sites, désactivez le fichier default dans sites-enabled. Retirez simplement le lien, mais vérifiez d’abord que votre bloc serveur fonctionne correctement.

4. Vérifiez la configuration et rechargez Nginx

Après chaque modification, testez la syntaxe avec sudo nginx -t. Si tout est OK, rechargez Nginx sans interruption : sudo systemctl reload nginx. reload est préférable à restart car il gère les connexions en douceur.

En cas d’erreur, le message précise généralement le nom du fichier et la ligne concernée. Les erreurs les plus courantes : point-virgule manquant, accolades mal placées, chemin incorrect ou collision de server_name. N’effectuez pas le reload tant que l’erreur n’est pas corrigée.

Ajouter un Second ou Troisième Site

L’avantage du multi-sites est la grande répétabilité une fois la première configuration réussie. Pour site2.com, créez /var/www/site2.com/public, rédigez /etc/nginx/sites-available/site2.com, adaptez root et les logs, créez le lien symbolique, testez la configuration.

Exemple de bloc serveur distinct :

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

Des logs séparés sont précieux en production. Par exemple, si un site génère des erreurs 404 et pas l’autre, vous localisez instantanément le problème. Cela facilite aussi l’analyse de trafic, la détection de bots, les liens cassés et les soucis de performance, site par site.

Configuration SSL et HTTPS

En 2026, le HTTPS n’est plus seulement un gage de sécurité : c’est un signal de confiance pour les utilisateurs et un critère de qualité technique. Les navigateurs marquent les sites HTTP comme non sécurisés ; SSL est obligatoire sur toute page de paiement, formulaire, espace membre ou administration. Pour un hébergement multi-sites, il faut un certificat adapté à chaque domaine. Pour vos besoins SSL, consultez certificats SSL.

Avec Let’s Encrypt, vous pouvez obtenir un certificat par domaine via Certbot. Ex : certbot --nginx -d site1.com -d www.site1.com détecte la configuration Nginx et ajoute le bloc HTTPS automatiquement. Après édition automatique, vérifiez toujours le fichier : parfois des doublons ou erreurs de redirection apparaissent.

En général, le trafic HTTP sur le port 80 est redirigé de façon permanente vers le port 443 (HTTPS). Une redirection 301 est recommandée pour indiquer à Google la version définitive du site. Décidez si vous souhaitez utiliser www ou non, et regroupez toutes les variantes sur une seule version canonique. Par exemple, si vous préférez https://site1.com, redirigez tout le trafic www vers la version sans www, sur HTTP et HTTPS, afin de réduire les risques de contenu dupliqué.

Blocs Serveur Nginx pour Sites PHP et WordPress

Pour les sites HTML statiques, la configuration est simple. Mais pour WordPress, Laravel ou toute appli PHP, il faut intégrer PHP-FPM. Définissez index.php et redirigez les requêtes PHP vers le socket adéquat : sur Ubuntu, pour PHP 8.3, le chemin est généralement /run/php/php8.3-fpm.sock (à adapter selon la version).

Exemple pour un site WordPress :

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

Pour WordPress, la règle try_files $uri $uri/ /index.php?$args est cruciale pour les permaliens. Pensez aussi à sécuriser xmlrpc.php, limiter wp-login.php par IP ou par rate limiting, interdire l’exécution PHP dans les dossiers uploads. Si vous hébergez plusieurs WordPress sur un VPS, créez une base de données et un utilisateur distinct par site, et appliquez une politique de mises à jour régulières. Pour une solution plus managée, explorez Hébergement WordPress.

Comparaison : Blocs Serveur Nginx vs Apache VirtualHost

Apache et Nginx permettent tous deux l’hébergement multi-sites, mais leur architecture diffère. Le choix dépend de vos besoins, habitudes et attentes en matière de performance.

Si votre application dépend beaucoup des règles .htaccess, Apache reste plus simple. Mais pour le reverse proxy, le cache et les flux de déploiement modernes, Nginx est souvent le meilleur choix. Certaines architectures combinent Nginx en proxy inverse et Apache en backend.

Bonnes Pratiques de Sécurité

Héberger plusieurs sites sur un serveur est économique, mais cela augmente la responsabilité en matière de sécurité. Pour éviter qu’une faille sur un site n’affecte tous les autres, appliquez l’isolation et le principe du moindre privilège.

• Créez une base de données et un utilisateur distinct par site.
• Limitez le dossier racine web au dossier public.
• Gardez les fichiers de sauvegarde, .env, .git, config et SQL hors du web.
• Renouvelez les certificats SSL régulièrement et forcez la redirection HTTPS.
• Utilisez un pare-feu comme UFW ; n’ouvrez que les ports nécessaires.
• Appliquez les mises à jour de Nginx et du système d’exploitation.
• Gardez des logs d’accès et d’erreur séparés par site.
• Restreignez l’accès aux panneaux d’administration par IP ou authentification supplémentaire.
• Évitez les permissions 777.

Ajoutez aussi des headers de sécurité : X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Content-Security-Policy. Testez d’abord la Content-Security-Policy en préproduction, car elle peut bloquer scripts et styles si mal configurée. Pour aller plus loin sur la sécurité, consultez Sécurité de site Web.

Performance et SEO : Points d’Attention

Les blocs serveur Nginx influencent la performance et la qualité SEO du site. Les chaînes de redirections mal gérées, erreurs de canonical, absence de compression gzip ou brotli, logs volumineux ou cache mal paramétré ralentissent le site. Google privilégie les sites rapides, sûrs et stables.

Définissez une version canonique unique par domaine. Faites une redirection directe : de HTTP vers HTTPS, de www vers non-www (ou l’inverse), sans étape intermédiaire. Évitez les chaînes de redirection du type : http://site.com → http://www.site.com → https://www.site.com → https://site.com. Privilégiez un unique 301 vers la cible.

Pour les fichiers statiques, utilisez les headers cache-control : images, CSS, JS peuvent être conservés en cache navigateur. Pour les fichiers qui changent souvent, utilisez la version dans le nom ou des query strings. La compression gzip réduit l’utilisation de la bande passante sur HTML, CSS, JS, JSON. Sur les sites à fort trafic, considérez le microcache Nginx, FastCGI cache ou l’intégration d’un CDN. Pour tout besoin CDN ou distribution globale, consultez Qu'est-ce que le CDN.

Gestion des Logs et Monitoring

Pour l’hébergement multi-sites, la gestion des logs est essentielle pour déboguer rapidement. Des logs séparés affichent clairement les erreurs par site : access_log pour les requêtes visiteurs, error_log pour les soucis de configuration, permissions, fichiers manquants ou problèmes de backend. Une erreur 502 Bad Gateway vient souvent de PHP-FPM ou d’un service backend, 403 Forbidden d’un souci de permissions ou d’absence d’index, 404 Not Found d’un chemin ou d’une règle try_files incorrecte.

Pour éviter que les fichiers log deviennent trop volumineux, configurez logrotate. Pour de petits sites, une rotation quotidienne ou hebdomadaire suffit. Les sites à fort trafic nécessitent une collecte centralisée, des métriques et alertes. Un disque plein empêche Nginx d’écrire les logs et peut rendre le site inaccessible. Fixez des seuils sur l’utilisation disque.

Erreurs Courantes et Solutions Rapides

Voici les problèmes les plus fréquents lors de la configuration des blocs serveur Nginx, et comment les résoudre :

• Un domaine affiche le mauvais site : vérifiez les collisions de server_name et le bloc serveur par défaut.
• Erreur 403 Forbidden : vérifiez le dossier root, les permissions et la présence d’un fichier index.
• Erreur 404 Not Found : vérifiez le chemin root et la règle try_files.
• Erreur 502 Bad Gateway : assurez-vous que PHP-FPM fonctionne et que le chemin du socket est correct.
• Certificat SSL affiché sur le mauvais site : vérifiez le server_name et les fichiers de certificat sur le port 443.
• Boucle de redirection : simplifiez les règles de redirection HTTP-HTTPS et www.
• Nginx ne recharge pas : corrigez l’erreur de syntaxe indiquée par nginx -t.

Les administrateurs expérimentés suivent une liste de contrôle simple : DNS correct ? Configuration Nginx activée ? Dossier root présent ? Permissions adéquates ? Test de syntaxe OK ? Que disent les logs ? Cette méthode permet de résoudre les problèmes sans paniquer.

Checklist Pratique pour l’Environnement de Production

Avant la mise en ligne, vérifiez chaque site avec la liste suivante. Pour les projets client, documenter ces points assure un standard professionnel.

• Le domaine pointe via A ou AAAA vers la bonne IP.
• Une seule version canonique est choisie (www ou non-www).
• Le trafic HTTP est redirigé en 301 vers HTTPS.
• Le certificat SSL est valide et le renouvellement automatique activé.
• Chaque site a un dossier root et des logs distincts.
• La configuration Nginx a été validée avec sudo nginx -t.
• Un plan de sauvegarde est défini, avec test de restauration.
• Les permissions des fichiers suivent le principe du moindre privilège.
• Le pare-feu n’ouvre que les ports nécessaires.
• Les logs d’erreur sont surveillés durant au moins 15 minutes après la mise en ligne.

Cette liste est simple, mais elle réduit grandement le risque de coupure. Les étapes de renouvellement SSL, vérification DNS et monitoring des logs détectent la plupart des problèmes invisibles à l’avance.

Conclusion

Les blocs serveur Nginx sont une méthode fiable pour héberger plusieurs sites sur un même serveur, avec organisation, sécurité et performance. Une structure de dossiers propre, des fichiers de configuration séparés, des règles de redirection claires, l’utilisation du HTTPS, la séparation des logs et des tests réguliers permettent une gestion efficace des sites, du simple portfolio aux multiples projets clients.

Avant de publier un nouveau projet, identifiez clairement vos besoins en nom de domaine, ressources serveur et certificat SSL, puis suivez la checklist pour configurer Nginx étape par étape. Si vous cherchez une infrastructure plus managée, explorez les solutions Packs d'hébergement, serveur VPS et certificats SSL de Hostragons pour choisir le point de départ adapté à votre projet.

Questions Fréquemment Posées

Combien de sites peut-on héberger avec des blocs serveur Nginx ?

Techniquement, il n’y a pas de limite sur le nombre de sites, cela dépend des ressources CPU, RAM, disque, trafic, charge base de données et capacité PHP-FPM. Sur des sites statiques à faible trafic, des dizaines sont possibles. Pour WordPress ou e-commerce à fort trafic, limitez le nombre pour garantir la stabilité.

Faut-il un certificat SSL par site ?

Oui : chaque domaine ou sous-domaine publié en HTTPS doit être couvert par un certificat. Vous pouvez utiliser des certificats individuels, SAN ou wildcard. L’essentiel est d’associer le bon fichier de certificat au bon server_name sur le port 443 dans Nginx.

Peut-on publier des sous-domaines avec un bloc serveur Nginx ?

Oui. Pour blog.site.com, panel.site.com, etc., définissez un server_name spécifique, et assignez un dossier racine ou une application backend différente. Côté DNS, créez un enregistrement A ou CNAME pour chaque sous-domaine.

Quelle différence entre sites-available et sites-enabled ?

sites-available contient les configurations disponibles ; sites-enabled celles activées. En général, on crée un lien symbolique depuis sites-enabled vers sites-available. Cela facilite l’activation ou la désactivation des sites.

Pourquoi mon site affiche un autre domaine ?

Les causes les plus courantes : DNS pointant vers la mauvaise IP, valeur server_name incorrecte, bloc serveur par défaut interceptant la requête ou mauvais bloc SSL sur le port 443. Vérifiez d’abord les enregistrements DNS, la sortie de nginx -t, les liens actifs dans sites-enabled et les logs d’accès.