Nginx est souvent déployé parce qu’il encaisse la charge sans broncher, mais c’est la façon dont les vhost sont organisés qui fait la différence entre un serveur web bricolé et une plateforme qui tient sur la durée. Les hôtes virtuels, appelés server blocks dans la documentation, permettent de séparer clairement chaque site, chaque API, chaque environnement de test, tout en restant sur la même machine et la même adresse IP.
Derrière cette notion assez théorique se cachent des choix très concrets : où placer les fichiers, comment nommer chaque fichier de configuration, quelles règles de redirection appliquer, comment traiter le SSL/TLS sans ajouter de dette technique.
Un cas assez courant résume bien l’enjeu. Une PME bascule progressivement ses applications internes sur le web : un site institutionnel, un outil métier en PHP, un tableau de bord en Node.js derrière un reverse proxy. Tout tourne sur un seul VPS. Sans une mise en place propre des server blocks dès le départ, la configuration devient vite illisible, les journaux d’erreurs se mélangent, et chaque ajout de domaine se transforme en loterie.
À l’inverse, quelques conventions simples (un répertoire par domaine, un fichier par vhost, une logique de logs claire) réduisent drastiquement le temps de diagnostic quand un site tombe le lundi matin. C’est ce pas-à-pas que ce texte détaille, en restant collé au terrain : commandes, exemples concrets, et quelques décisions assumées sur ce qu’il vaut mieux éviter.
En bref
- Les server blocks Nginx permettent d’héberger plusieurs sites ou API sur un même serveur web en isolant leur configuration.
- Une bonne organisation des répertoires et de chaque fichier de configuration évite les effets de bord lors des mises à jour.
- Mettre en place un vhost HTTP propre dès le début simplifie ensuite l’ajout du SSL/TLS et des redirections HTTPS.
- L’usage de Nginx comme reverse proxy pour des applis Node, Python ou conteneurisées repose sur les mêmes mécaniques de server blocks.
- Tester systématiquement la configuration avant un reload et tracer les accès par site limite les interruptions de service inutiles.
Comprendre les vhost Nginx et poser une architecture simple dès le départ
La mécanique des hôtes virtuels existe depuis longtemps dans le monde Apache, mais dans Nginx il s’agit de server blocks définis à l’intérieur du contexte http. Chaque bloc commence par server { } et décrit comment Nginx doit traiter les requêtes arrivant sur un ou plusieurs noms de domaine.
Tant que ces blocs sont clairs, la plateforme reste maîtrisable, même avec une dizaine de sites ou microservices.
Le premier point à clarifier reste la relation entre DNS et Nginx. Le DNS ne connaît que des enregistrements du type A ou AAAA vers une IP. Dans un exemple classique, le domaine www.gameking.tips pointe vers l’adresse IP 35.160.86.106. Le résolveur amène tout le trafic HTTP(S) vers cette IP, et la sélection du bon site se fait ensuite via la directive server_name dans la configuration Nginx. Mélanger ces deux couches du raisonnement crée beaucoup de confusion chez les équipes qui débutent.
Une structure robuste repose sur trois briques : un répertoire de contenu par site, un fichier de configuration dédié, et des logs séparés. Sur un Rocky Linux 9 ou une Ubuntu 22.04, cela donne généralement un dossier /var/www/exemple.com/ pour les fichiers, un fichier /etc/nginx/conf.d/exemple.com.conf ou /etc/nginx/sites-available/exemple.com, et des journaux /var/log/nginx/exemple.com.access.log et error.log. Sur le terrain, cette séparation simplifie énormément l’analyse quand un seul site commence à renvoyer des 502 ou des 404 en série.
Une position s’impose ici : mélanger plusieurs domaines dans un même server block pour « faire court » est une mauvaise idée. Cela peut sembler plus rapide le jour de la mise en production, mais au premier audit de sécurité ou au premier changement de politique de cache par domaine, tout devient bloqué. Mieux vaut un fichier par domaine, quitte à mutualiser certaines parties via l’instruction include pour les blocs communs (gzip, en-têtes de sécurité, paramètres FastCGI, etc.).
Enfin, un point trop souvent négligé concerne la documentation locale. Quelques lignes de commentaire en début de fichier de configuration pour indiquer le propriétaire applicatif, le contact, l’environnement (prod, préprod, demo), évitent des heures perdues quand l’équipe change. Cette simple habitude vaut plus qu’un wiki jamais à jour.
Installer Nginx et vérifier l’environnement avant de créer un vhost
Avant de parler de vhost, il faut s’assurer que Nginx est proprement installé et maîtrisé sur le système. Sur un Rocky Linux 9, une commande dnf info nginx permet de vérifier la présence du paquet et sa version. En cas d’absence, dnf install nginx installe le serveur web avec les chemins standards. Côté Ubuntu, l’équivalent se fait avec apt update puis apt install nginx. Se passer de cette étape de vérification conduit parfois à des surprises, notamment quand plusieurs dépôts coexistent.
Une fois Nginx en place, il devient utile de connaître au moins deux commandes de base du service : systemctl status nginx pour l’état, et systemctl restart nginx ou reload pour appliquer les changements. Certaines équipes gardent également journalctl -u nginx dans leurs réflexes pour inspecter les logs du service. C’est cette boucle rapide édition/test/reload qui donne de la confiance quand on enchaîne plusieurs créations de vhost.
Pour sécuriser ces manipulations, un réflexe gagnant consiste à vérifier la syntaxe avant tout redémarrage. Sur ce point, un guide dédié comme celui détaillé sur ce tutoriel de test de configuration Nginx apporte des commandes prêtes à l’emploi et quelques pièges typiques. De nombreux incidents auraient pu être évités avec un simple nginx -t lancé systématiquement dans les scripts de déploiement.
Ce socle opérationnel en place, la création d’un premier server block devient beaucoup plus sereine. C’est aussi le bon moment pour décider d’un schéma de nommage stable : par exemple, conserver une cohérence stricte entre le nom de domaine et le nom du fichier de configuration, sans acronymes obscurs.
Créer pas à pas un vhost Nginx : du répertoire au server block
La création d’un vhost se résume à une séquence toujours identique : préparer le contenu, décrire le comportement dans un fichier de configuration, activer puis tester. L’exemple suivant s’appuie sur un domaine fictif exemple.com, mais la logique est transposable à n’importe quel autre nom.
Premier geste, créer le répertoire racine. Sur un système classique, cela donnera quelque chose comme mkdir -p /var/www/exemple.com, suivi de droits adaptés (souvent chown vers un utilisateur système spécifique, plutôt que root). Déposer ensuite une page simple index.html permet de disposer très vite d’une preuve de bon fonctionnement. Une variante pratique, surtout pour un site de test, consiste à afficher l’hostname et la date dans cette page, histoire de vérifier visuellement quelle machine répond.
Deuxième étape, créer le fichier de configuration. Sur Rocky Linux, la convention /etc/nginx/conf.d/exemple.com.conf fonctionne bien. Le squelette minimal ressemble à ceci :
server {
listen 80;
server_name exemple.com www.exemple.com;
root /var/www/exemple.com;
location / {
index index.php index.html index.htm;
}
}
Chacune de ces directives joue un rôle simple mais clé. listen 80 indique que ce server block traite les requêtes HTTP classiques. server_name liste les noms que Nginx doit associer à ce site, y compris les variantes avec et sans www. La directive root pointe vers le répertoire de fichiers. Enfin, le bloc location / définit l’ordre de priorité des fichiers à servir par défaut, ce qui reste utile quand PHP et HTML cohabitent.
Certains administrateurs groupent dès le départ les erreurs et logs dans ce bloc, en ajoutant par exemple :
access_log /var/log/nginx/exemple.com.access.log;
error_log /var/log/nginx/exemple.com.error.log;
C’est un choix assumé à recommander, car il évite de fouiller dans un fichier global pour diagnostiquer les soucis d’un seul site. Ignorer cette bonne pratique devient douloureux dès qu’un troisième ou quatrième domaine rejoint le même serveur.
Une fois le fichier en place, un nginx -t permet de vérifier la cohérence syntaxique. Si tout va bien, un systemctl restart nginx ou un reload active immédiatement le nouveau vhost. Un test rapide via curl http://exemple.com ou un navigateur valide alors la chaîne DNS → Nginx → fichiers. Cette boucle courte rend la démarche prédictible, ce qui n’est jamais un luxe en production.
Tableau comparatif des chemins et conventions fréquentes pour les vhost Nginx
Pour éviter les confusions entre distributions, un petit récapitulatif ne fait pas de mal, surtout dans des équipes qui jonglent entre plusieurs environnements.
| Distribution | Dossier contenu (root) | Dossier config vhost | Méthode d’activation |
|---|---|---|---|
| Rocky Linux / RHEL 9 | /var/www/domaine/ | /etc/nginx/conf.d/domaine.conf | Fichier directement lu par Nginx, pas de lien symbolique |
| Ubuntu / Debian | /var/www/domaine/ | /etc/nginx/sites-available/domaine | Lien symbolique vers /etc/nginx/sites-enabled/ |
| VPS managé ou conteneur | Variable selon l’image (ex. /srv/www/) | Souvent /etc/nginx/conf.d/ | Souvent géré par des scripts ou Ansible/Terraform |
Ce tableau ne couvre pas tous les cas possibles, mais suffit à éviter plusieurs malentendus. Dans le doute, mieux vaut inspecter le fichier nginx.conf d’origine pour voir quels dossiers sont effectivement inclus.
Ajouter le HTTPS : SSL/TLS, redirections et bonnes pratiques par vhost
Dès que le premier site commence à recevoir du trafic réel, déployer le SSL/TLS devient quasiment non négociable. Non seulement pour la sécurité, mais aussi parce qu’une bonne partie des navigateurs affichent désormais des avertissements explicites en HTTP clair. La bonne nouvelle, c’est qu’avec des vhost bien séparés, l’ajout du HTTPS reste relativement mécanique.
Le principe est toujours le même : un server block pour l’écoute HTTP qui se contente de rediriger en 301 vers HTTPS, et un bloc dédié au port 443 avec les certificats et les options de chiffrement. Pour exemple.com, cela donne souvent :
server {
listen 80;
server_name exemple.com www.exemple.com;
return 301 https://exemple.com$request_uri;
}
Puis un second bloc :
server {
listen 443 ssl;
server_name exemple.com;
root /var/www/exemple.com;
ssl_certificate /etc/letsencrypt/live/exemple.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/exemple.com/privkey.pem;
location / {
index index.php index.html;
}
}
La séparation claire entre HTTP et HTTPS simplifie beaucoup les diagnostics. Quand une redirection tourne en boucle, on sait exactement quel bloc inspecter. Quand un certificat Nginx expire, un simple nginx -t avant reload permet de détecter un chemin manquant ou des droits mal réglés. Là encore, l’usage systématique de noms de fichiers cohérents par domaine réduit les risques de confusion.
Pour les certificats, la combinaison Let’s Encrypt + Certbot reste le standard de fait pour la majorité des petites structures. Chaque domaine obtient son couple de fichiers, stocké dans un répertoire dédié. Ne pas mélanger les certificats entre hôtes virtuels évite des situations étranges où un site de démonstration répond avec un certificat destiné à un domaine de production. Cela arrive plus souvent qu’on ne le croit quand les blocs sont copiés-collés sans relecture.
Une autre recommandation mérite d’être répétée : résister à la tentation des wildcards dès le début. Les certificats génériques ont leur place, surtout pour des sous-domaines nombreux, mais pour un premier déploiement simple, un certificat par domaine reste plus lisible et moins piégeux. Plusieurs incidents de sécurité publiés ces dernières années ont montré que des compromis partiels sur un sous-domaine pouvaient exposer l’ensemble du certificat wildcard.
Une fois le HTTPS en place et testé, cette couche devient surtout un prérequis tranquille, qui n’ajoute plus de charge mentale au quotidien. C’est justement ce que l’on attend d’une bonne configuration.
Utiliser Nginx comme reverse proxy dans un vhost
Beaucoup de projets actuels combinent Nginx et des applications tournant en arrière-plan sur d’autres ports : Node.js, Python avec Gunicorn, conteneurs sur un port 8080, etc. Dans ce modèle, le vhost Nginx joue le rôle de reverse proxy, exposant l’application au monde extérieur tout en restant le point d’entrée unique.
Concrètement, cela se traduit souvent par un bloc de type :
location / {
proxy_pass http://127.0.0.1:3000;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
Intégré à un server block dédié à un domaine précis, ce schéma permet par exemple d’héberger app.exemple.com qui pointe vers une application Node locale, tandis que www.exemple.com reste un site statique servi directement depuis le système de fichiers. Cette capacité à combiner plusieurs types de backends sous une même bannière Nginx explique largement son adoption en environnement IoT, où des dashboards, des APIs REST et des frontends cohabitent sur une même machine.
Une erreur fréquente consiste à mutualiser un même reverse proxy pour plusieurs domaines, en espérant gagner du temps. Dans les faits, cela complexifie les règles de routage et multiplie les risques de fuite de headers ou de cookies entre sites. Mieux vaut un vhost par application et par domaine, quitte à regrouper certaines directives proxy communes dans un fichier inclus.
Exemple fil rouge : un VPS unique, trois domaines, trois vhost Nginx
Pour rendre ces principes plus concrets, prenons un scénario très classique. Une petite entreprise loue un VPS sur lequel elle souhaite héberger trois usages différents : un site public www.societe.fr, une interface interne intra.societe.fr, et un tableau de bord IoT iot.societe.fr. Plutôt que de multiplier les machines virtuelles, l’équipe choisit de capitaliser sur les server blocks Nginx.
La première décision consiste à séparer les racines de contenu : /var/www/www.societe.fr/ pour le site public, /var/www/intra.societe.fr/ pour l’intranet (restreint en IP ou avec authentification), et /var/www/iot.societe.fr/ pour le frontend des capteurs. L’application IoT réelle tourne en réalité sur un port 5000, accessible uniquement en local, derrière un vhost configuré en reverse proxy.
Chaque instance obtient ensuite son propre fichier de configuration dans /etc/nginx/conf.d/. Pour le site public, un bloc HTTPS classique suffit. Pour l’intranet, l’administrateur ajoute des directives de restriction, soit par adresse IP, soit via une authentification basique. Pour le dashboard IoT, le server block se contente de gérer le certificat SSL/TLS et de transférer les requêtes vers le backend Python, tout en posant quelques en-têtes supplémentaires pour le CORS si nécessaire.
Au passage, ce découpage facilite la discussion avec la DSI ou le RSSI. Chaque vhost correspond à un périmètre fonctionnel et à une politique de sécurité, ce qui rend les audits plus ciblés. Quand l’entreprise décide ensuite de déplacer l’intranet sur un autre serveur, le fait de disposer d’un fichier dédié rend la migration nettement moins risquée : il suffit de dupliquer ce bloc, mettre à jour le DNS et désactiver l’ancien vhost.
Pour des infrastructures plus grandes, ce modèle se transpose naturellement avec des outils de gestion d’infrastructure. Les rôles Ansible, les playbooks Terraform ou les templates Cloud-init reprennent ces mêmes conventions de nommage et de séparation, ce qui limite les écarts entre machines de test et production.
Un dernier bénéfice, rarement évoqué, concerne la formation des nouveaux arrivants. Leur faire lire trois blocs server bien structurés les familiarise rapidement avec le fonctionnement global, beaucoup mieux qu’un unique fichier tentaculaire où tous les domaines seraient entassés. L’apprentissage suit alors la logique des objets métier plutôt que celle d’un fichier monolithique.
Tester, diagnostiquer et fiabiliser ses hôtes virtuels Nginx dans la durée
Une configuration de vhost Nginx qui fonctionne le jour de la mise en service ne garantit rien sur la durée. Les domaines expirent, les certificats doivent être renouvelés, les applications changent de port ou de dépendances. L’enjeu devient donc de mettre en place une hygiène de vérification et de diagnostic qui ne repose pas uniquement sur le hasard ou les retours des utilisateurs finaux.
Le premier réflexe, déjà évoqué, reste l’usage systématique de nginx -t avant tout redémarrage, qu’il soit manuel ou automatisé. Beaucoup d’équipes vont plus loin et ajoutent une vérification externe après chaque déploiement, par exemple un script qui enchaîne des requêtes curl sur chaque domaine attendu et alerte en cas de code HTTP inattendu. Cela paraît basique, mais sur un pool de 10 ou 15 vhost, ce genre de test automatique signale rapidement un oubli de certificat ou un changement de port backend mal répercuté.
Les journaux d’accès par site deviennent aussi des outils de diagnostic précieux. Un pic de 404 sur un seul domaine, observé sur exemple.com.access.log, raconte une histoire très différente d’un 502 intermittent sur un autre vhost. C’est précisément pour cette raison que séparer les logs par site fait gagner du temps. Mélanger tous les accès dans un unique fichier global rend ces signaux beaucoup plus difficiles à lire.
Pour les environnements où la virtualisation ou le VDI jouent un rôle, des formations plus globales sur les couches d’infrastructure, comme celles que l’on trouve sur des parcours VMware vSphere et Horizon, aident à mieux comprendre comment les vhost Nginx s’intègrent dans une architecture complète. Même si Nginx reste une brique applicative, sa bonne configuration dépend souvent de décisions prises bien plus bas dans la pile (répartition de charge, DNS interne, sécurité réseau).
Enfin, aborder dès le début la question de la maintenance programmatique des vhost évite le « fichier Frankenstein » au bout de quelques années. Utiliser des blocs include pour les règles communes, versionner les fichiers de configuration dans un dépôt Git, documenter les changements avec des commits lisibles, tout cela prépare le terrain pour des évolutions plus ambitieuses : ajout d’un CDN, introduction d’un WAF, découpage progressif en microservices.
En filigrane, l’idée reste toujours la même : un vhost Nginx bien pensé n’est pas seulement un bout de texte dans un fichier, c’est un élément de l’architecture qui doit rester explicite, testable et remplaçable. Quand ce niveau de clarté est atteint, ajouter un nouveau domaine devient une routine, pas un pari.
Comment créer rapidement un nouveau vhost Nginx pour un domaine simple ?
Commencer par créer le répertoire du site, par exemple /var/www/mon-domaine, puis une page index.html de test. Ajouter ensuite un fichier de configuration dans /etc/nginx/conf.d/ ou sites-available avec un bloc server qui définit listen 80, server_name et root. Tester la syntaxe avec nginx -t, recharger Nginx, puis vérifier l’accès au domaine dans un navigateur ou avec curl.
Faut-il un server block séparé pour le HTTP et le HTTPS ?
Oui, c’est une bonne pratique. Un bloc écoute sur le port 80 et redirige en 301 vers l’URL en HTTPS, un autre bloc écoute sur 443 avec les paramètres SSL/TLS et la racine du site. Cette séparation rend les règles de redirection plus lisibles et facilite le diagnostic des erreurs liées aux certificats ou aux ports.
Comment utiliser Nginx comme reverse proxy pour une application Node ou Python ?
Dans le vhost associé au domaine, il suffit de définir un bloc location / avec une directive proxy_pass vers l’URL interne de l’application, par exemple http://127.0.0.1:3000. Il est recommandé d’ajouter proxy_set_header Host, X-Real-IP et X-Forwarded-For pour que l’application backend reçoive les bonnes informations sur le client et le domaine appelé.
Quelles erreurs fréquentes éviter dans la configuration des hôtes virtuels Nginx ?
Les pièges classiques sont le mélange de plusieurs domaines dans un même server block, l’oubli de redirection HTTP vers HTTPS, l’absence de test nginx -t avant un restart et des logs non séparés par site. Une autre erreur courante consiste à copier-coller des blocs sans adapter les chemins de certificats SSL/TLS ou la directive server_name.
Comment diagnostiquer un vhost qui répond en 502 Bad Gateway ?
Un 502 indique généralement que le backend n’est pas joignable ou qu’il refuse les connexions. Il faut vérifier proxy_pass ou fastcgi_pass dans le vhost, tester le port en local avec curl ou telnet, et consulter le fichier error_log du site. Un changement de port backend ou un service arrêté sont souvent en cause, plus rarement un problème dans Nginx lui-même.