Comment configurer les hôtes virtuels dans Nginx sur Ubuntu

La configuration des hôtes virtuels dans Nginx est l’une des techniques les plus puissantes pour héberger plusieurs sites Web sur un seul serveur, chacun avec son propre nom de domaine, répertoire racine et configuration indépendante. Nginx gère cela via des blocs serveur — des unités de configuration flexibles et légères qui définissent comment le serveur Web répond aux demandes pour chaque domaine.

Que vous gériez un portfolio personnel, exécutiez des sites clients ou fassiez évoluer une application multi-locataire, ce guide fournit une procédure complète et prête pour la production pour configurer les hôtes virtuels Nginx sur Ubuntu. Nous couvrirons la structure des répertoires, la configuration des blocs serveur, l’activation des sites, la configuration SSL/HTTPS et le dépannage — tout ce dont vous avez besoin pour passer de zéro à un serveur Nginx multi-sites entièrement fonctionnel.

> Vous cherchez un serveur Ubuntu fiable pour suivre ? Les plans VPS Hosting d’AlexHost vous donnent un accès root complet, un stockage SSD et un déploiement instantané — parfait pour ce cas d’usage exact.

Table des matières

1. Prérequis
2. Configurer les répertoires pour chaque site Web
3. Créer un contenu HTML exemple
4. Créer des fichiers de configuration d’hôte virtuel
5. Activer les hôtes virtuels
6. Tester la configuration Nginx
7. Redémarrer Nginx pour appliquer les modifications
8. Accéder à vos sites Web
9. Activer HTTPS avec Let’s Encrypt (Recommandé)
10. Dépannage des problèmes courants
11. Conclusion

Prérequis

Avant de commencer, assurez-vous que les conditions suivantes sont remplies :

Nginx installé sur votre serveur

Si Nginx n’est pas encore installé, exécutez les commandes suivantes sur votre serveur Ubuntu :

sudo apt update
sudo apt install nginx

Vérifiez l’installation et vérifiez que le service est en cours d’exécution :

sudo systemctl status nginx

Vous devriez voir active (running) dans la sortie. Si ce n’est pas le cas, démarrez-le manuellement :

sudo systemctl start nginx
sudo systemctl enable nginx

Noms de domaine pointant vers votre serveur

Chaque hôte virtuel nécessite un nom de domaine qui se résout en l’adresse IP publique de votre serveur. Vous devrez créer des enregistrements A dans vos paramètres DNS pointant vers l’IP du serveur.

> Besoin d’un domaine ? Enregistrez le vôtre via AlexHost Domain Registration et gérez les enregistrements DNS directement depuis votre panneau de contrôle.

À des fins de test local, vous pouvez contourner complètement le DNS en modifiant votre fichier /etc/hosts (couvert à l’étape 7).

Autorisations requises

Vous aurez besoin de privilèges sudo sur votre serveur Ubuntu pour créer des répertoires, modifier les fichiers de configuration et gérer le service Nginx.

Étape 1 : Configurer les répertoires pour chaque site Web

Chaque site Web hébergé sur votre serveur doit avoir son propre répertoire isolé pour stocker les fichiers Web. Cette séparation garde vos projets organisés et prévient les conflits de configuration.

Dans ce guide, nous allons configurer deux domaines exemples : example1.com et example2.com. Remplacez-les par vos noms de domaine réels tout au long.

Créer les répertoires racine Web

sudo mkdir -p /var/www/example1.com/html
sudo mkdir -p /var/www/example2.com/html

Le drapeau -p crée tous les répertoires intermédiaires selon les besoins.

Attribuer la propriété correcte

Accordez la propriété de ces répertoires à www-data, l’utilisateur système sous lequel Nginx s’exécute :

sudo chown -R www-data:www-data /var/www/example1.com/html
sudo chown -R www-data:www-data /var/www/example2.com/html

Cela garantit que Nginx dispose des autorisations de lecture nécessaires pour servir les fichiers de ces répertoires.

Définir les autorisations des répertoires

sudo chmod -R 755 /var/www

L’autorisation 755 signifie que le propriétaire a un accès complet en lecture/écriture/exécution, tandis que les groupes et autres utilisateurs ont un accès en lecture et exécution — approprié pour le contenu Web servi publiquement.

Étape 2 : Créer un contenu HTML exemple

Pour vérifier que chaque hôte virtuel fonctionne correctement, créez un fichier index.html simple pour chaque site.

Pour example1.com

echo "<h1>Welcome to Example1.com!</h1>" | sudo tee /var/www/example1.com/html/index.html

Pour example2.com

echo "<h1>Welcome to Example2.com!</h1>" | sudo tee /var/www/example2.com/html/index.html

Ces pages d’espace réservé confirmeront que Nginx achemine les demandes vers la racine de document correcte pour chaque domaine.

Étape 3 : Créer des fichiers de configuration d’hôte virtuel

Nginx stocke les fichiers de configuration du site dans /etc/nginx/sites-available/. Chaque fichier définit un bloc serveur — l’équivalent Nginx d’un hôte virtuel Apache. Les sites activés sont ensuite liés symboliquement dans /etc/nginx/sites-enabled/.

Configuration pour example1.com

Créez un nouveau fichier de configuration :

sudo nano /etc/nginx/sites-available/example1.com

Ajoutez le bloc serveur suivant :

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

    server_name example1.com www.example1.com;

    root /var/www/example1.com/html;
    index index.html index.htm;

    access_log /var/log/nginx/example1.com.access.log;
    error_log  /var/log/nginx/example1.com.error.log;

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

Enregistrez et fermez le fichier (Ctrl+X, puis Y, puis Enter).

Configuration pour example2.com

Créez un deuxième fichier de configuration :

sudo nano /etc/nginx/sites-available/example2.com

Ajoutez le bloc serveur suivant :

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

    server_name example2.com www.example2.com;

    root /var/www/example2.com/html;
    index index.html index.htm;

    access_log /var/log/nginx/example2.com.access.log;
    error_log  /var/log/nginx/example2.com.error.log;

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

Directives clés expliquées

Étape 4 : Activer les hôtes virtuels

Nginx active les sites en créant des liens symboliques de sites-available vers sites-enabled. Cette conception vous permet de préparer les configurations sans les activer immédiatement.

sudo ln -s /etc/nginx/sites-available/example1.com /etc/nginx/sites-enabled/
sudo ln -s /etc/nginx/sites-available/example2.com /etc/nginx/sites-enabled/

Supprimer le site par défaut (Facultatif mais recommandé)

Si vous souhaitez empêcher la page d’espace réservé par défaut de Nginx d’interférer, désactivez-la :

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

Vous pouvez toujours la réactiver plus tard en recréant le lien symbolique.

Étape 5 : Tester la configuration Nginx

Avant de redémarrer Nginx, validez toujours vos fichiers de configuration pour les erreurs de syntaxe. Un fichier mal configuré peut arrêter tous les sites sur le serveur.

sudo nginx -t

Un test réussi retourne :

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

Si vous voyez des erreurs, Nginx indiquera le fichier et le numéro de ligne où le problème s’est produit. Vérifiez le fichier de configuration pertinent et corrigez les fautes de frappe ou les points-virgules manquants avant de continuer.

Étape 6 : Redémarrer Nginx pour appliquer les modifications

Une fois le test de configuration réussi, rechargez ou redémarrez Nginx pour appliquer vos modifications :

sudo systemctl restart nginx

Vous pouvez également utiliser reload pour un redémarrage gracieux qui n’interrompt pas les connexions actives :

sudo systemctl reload nginx

Étape 7 : Accéder à vos sites Web

Si le DNS est déjà configuré

Si vos noms de domaine pointent déjà vers l’adresse IP de votre serveur via des enregistrements DNS A, ouvrez simplement un navigateur et accédez à :

• http://example1.com
• http://example2.com

Vous devriez voir les messages « Bienvenue » respectifs que vous avez créés à l’étape 2.

Pour les tests locaux (sans DNS)

Si vous testez localement ou si le DNS n’a pas encore été propagé, vous pouvez simuler la résolution de domaine en modifiant le fichier /etc/hosts de votre machine locale (sur Linux/macOS) ou C:WindowsSystem32driversetchosts (sur Windows).

Ouvrez le fichier avec des privilèges élevés :

sudo nano /etc/hosts

Ajoutez les lignes suivantes, en remplaçant YOUR_SERVER_IP par l’IP réelle de votre serveur :

YOUR_SERVER_IP example1.com www.example1.com
YOUR_SERVER_IP example2.com www.example2.com

Enregistrez le fichier et testez dans votre navigateur. N’oubliez pas de supprimer ces entrées une fois que vos enregistrements DNS réels seront actifs.

Étape 8 : Activer HTTPS avec Let’s Encrypt (Recommandé)

L’exécution de sites Web en HTTP simple n’est plus acceptable pour les environnements de production. HTTPS chiffre le trafic entre votre serveur et les visiteurs, améliore les classements SEO et est requis pour les fonctionnalités modernes du navigateur. Let’s Encrypt fournit des certificats SSL/TLS gratuits et automatiquement renouvelables.

> Préférez une solution SSL premium ? AlexHost propose des Certificats SSL de confiance pour les entreprises qui ont besoin d’une validation étendue ou d’une couverture générique.

Installer Certbot

sudo apt install certbot python3-certbot-nginx

Obtenir et installer des certificats SSL

Exécutez Certbot pour chaque domaine. Le plugin --nginx modifie automatiquement votre configuration Nginx pour activer HTTPS :

sudo certbot --nginx -d example1.com -d www.example1.com

sudo certbot --nginx -d example2.com -d www.example2.com

Suivez les invites interactives. Certbot va :

1. Vérifier la propriété du domaine via un défi HTTP
2. Obtenir un certificat signé de Let’s Encrypt
3. Mettre à jour automatiquement votre bloc serveur Nginx pour écouter sur le port 443
4. Configurer la redirection HTTP vers HTTPS

Vérifier le renouvellement automatique

Les certificats Let’s Encrypt expirent tous les 90 jours. Certbot installe un minuteur systemd pour gérer les renouvellements automatiquement. Testez-le avec :

sudo certbot renew --dry-run

Si le test à sec se termine sans erreurs, vos certificats se renouvelleront automatiquement sans intervention manuelle.

À quoi ressemblera votre bloc serveur mis à jour

Après l’exécution de Certbot, votre configuration sera automatiquement mise à jour pour ressembler à quelque chose comme ceci :

server {
    listen 443 ssl;
    server_name example1.com www.example1.com;

    root /var/www/example1.com/html;
    index index.html;

    ssl_certificate /etc/letsencrypt/live/example1.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example1.com/privkey.pem;
    include /etc/letsencrypt/options-ssl-nginx.conf;
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem;

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

server {
    listen 80;
    server_name example1.com www.example1.com;
    return 301 https://$host$request_uri;
}

Dépannage des problèmes courants

Même avec une configuration prudente, des problèmes peuvent survenir. Voici les problèmes les plus courants et comment les résoudre :

502 Bad Gateway

Cela signifie généralement que Nginx ne peut pas communiquer avec un service backend (par exemple, PHP-FPM ou une application Node.js). Vérifiez que le service en amont s’exécute et que le socket/port dans votre configuration est correct.

403 Forbidden

Généralement un problème d’autorisations. Vérifiez que www-data possède la racine Web et que les autorisations de fichier sont définies correctement :

sudo chown -R www-data:www-data /var/www/example1.com
sudo chmod -R 755 /var/www/example1.com

404 Not Found

Vérifiez que la directive root dans votre bloc serveur pointe vers le répertoire correct et que index.html existe à ce chemin.

Mauvais site chargé

Si la visite de example1.com charge le contenu de example2.com, vérifiez que :

• Chaque directive server_name est unique et correcte
• Les liens symboliques dans sites-enabled sont valides : ls -la /etc/nginx/sites-enabled/
• Le site par défaut est désactivé s’il entre en conflit

Nginx ne démarre pas après la modification de la configuration

Exécutez toujours sudo nginx -t avant de redémarrer. Examinez attentivement la sortie d’erreur — elle pointera vers le fichier exact et la ligne causant le problème.

Vérification des journaux

Les journaux par site (configurés à l’étape 3) sont votre meilleure ressource de débogage :

sudo tail -f /var/log/nginx/example1.com.error.log
sudo tail -f /var/log/nginx/example1.com.access.log

Considérations avancées

Hébergement