Installer Nginx et configurer ses premiers vhosts

📍 Article principal du parcours : Nginx : reverse proxy, HTTPS et configuration de A à Z
Ce tutoriel ouvre le parcours Nginx. Pour la vue d’ensemble, lisez d’abord le guide principal.

Vous venez de louer un VPS, vous y êtes connecté en SSH, et vous avez le code du front de « Colis Express » prêt à mettre en ligne — une simple page HTML pour l’instant, mais c’est un vrai début. Il manque le serveur web qui va l’exposer au monde. Dans ce tutoriel, vous installez Nginx, vous servez cette page sur votre nom de domaine, puis vous apprenez à héberger un second site sur la même machine. À la fin, vous saurez écrire et activer un bloc server proprement, sans toucher au fichier de configuration principal.

🎯 Ce que vous allez apprendre

• Installer Nginx sur Ubuntu ou Debian et vérifier qu’il tourne.
• Comprendre l’arborescence de configuration et la convention sites-available / sites-enabled.
• Écrire un bloc server qui sert un site statique sur votre domaine.
• Tester et recharger la configuration sans couper le service.
• Héberger un deuxième domaine sur la même IP (virtual hosting).

🛠️ Ce que vous allez construire

À la fin de ce tutoriel, http://colis-express.net affichera la page d’accueil statique de votre projet, servie par Nginx depuis un répertoire dédié. Vous aurez en prime un second bloc server de démonstration prêt à accueillir un autre site, pour prouver qu’une seule machine peut en héberger plusieurs.

Prérequis

• Un serveur sous Ubuntu 24.04 LTS ou Debian 12 (les commandes sont identiques), avec un accès SSH et les droits sudo.
• Un nom de domaine dont l’enregistrement DNS A pointe vers l’IP publique du serveur.
• Niveau débutant à intermédiaire. Test express : si vous savez vous connecter en SSH et éditer un fichier avec nano, vous êtes prêt.
• ⏱️ Temps estimé : ~30 minutes.

Étape 1 — Installer Nginx

Avant d’installer quoi que ce soit, on rafraîchit la liste des paquets pour récupérer les versions à jour des dépôts de la distribution. Cette habitude évite d’installer une version périmée et de buter sur des dépendances obsolètes.

sudo apt update
sudo apt install nginx

L’installation place les binaires, crée l’arborescence dans /etc/nginx/, et — c’est important — démarre déjà un service Nginx avec une page par défaut. Vérifiez immédiatement que le service est actif : systemctl status nginx doit afficher active (running) en vert. Si vous ouvrez l’IP de votre serveur dans un navigateur, la page « Welcome to nginx! » s’affiche. Le serveur web tourne déjà ; tout le reste consistera à lui dire quoi servir.

✅ Point d’étape — systemctl status nginx indique active (running) et la page de bienvenue répond sur l’IP du serveur. Si ce n’est pas le cas, vérifiez que le port 80 est ouvert sur le pare-feu avec sudo ufw allow 'Nginx Full'.

Étape 2 — Comprendre l’arborescence de configuration

Avant d’écrire la moindre ligne, il faut savoir où les choses vivent, sous peine de modifier le mauvais fichier. Sur Debian et Ubuntu, Nginx suit une convention claire qui sépare le réglage global des configurations de chaque site.

/etc/nginx/
├── nginx.conf            # configuration globale (worker, gzip, includes)
├── sites-available/      # tous les sites, activés ou non
│   └── default
├── sites-enabled/        # liens symboliques vers les sites actifs
│   └── default -> ../sites-available/default
├── conf.d/               # fragments de configuration globaux
└── snippets/             # morceaux réutilisables (ex. réglages SSL)

La logique est la suivante : on écrit la configuration d’un site dans sites-available/, puis on l’« allume » en créant un lien symbolique vers sites-enabled/. Le fichier nginx.conf contient une ligne include /etc/nginx/sites-enabled/*; qui charge automatiquement tout ce qui s’y trouve. Cette séparation permet de désactiver un site sans perdre sa configuration : on supprime juste le lien, pas le fichier. Notez que les paquets fournis par nginx.org (et non par la distribution) utilisent plutôt conf.d/ sans la paire sites-available/enabled ; nous suivons ici la convention Debian/Ubuntu, la plus répandue.

Étape 3 — Préparer les fichiers du site

On ne sert jamais un site depuis n’importe où : on lui réserve un répertoire dédié, hors des chemins système, avec des droits propres. Créons l’emplacement du front de Colis Express et une page d’accueil minimale.

sudo mkdir -p /var/www/colis-express/html
echo '<h1>Colis Express — suivi de vos livraisons</h1>' \
  | sudo tee /var/www/colis-express/html/index.html
sudo chown -R www-data:www-data /var/www/colis-express

La dernière commande donne la propriété des fichiers à l’utilisateur www-data, sous lequel tournent les processus de travail de Nginx. C’est une bonne pratique : le serveur n’a besoin que de lire ces fichiers, et leur attribuer le bon propriétaire évite à la fois les erreurs de permission (« 403 Forbidden ») et l’exposition inutile. Le répertoire html imbriqué vous laissera de la place pour ranger plus tard les logs ou d’autres ressources à côté, sans tout mélanger.

✅ Point d’étape — Le fichier /var/www/colis-express/html/index.html existe et appartient à www-data. Vérifiez avec ls -l /var/www/colis-express/html.

Étape 4 — Écrire le bloc server

C’est le cœur du tutoriel. On va décrire à Nginx un site virtuel : sur quel port il écoute, à quel nom de domaine il répond, et où trouver les fichiers à servir. Créons le fichier de configuration du site.

sudo nano /etc/nginx/sites-available/colis-express

Collez-y la configuration suivante, puis enregistrez :

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

    server_name colis-express.net www.colis-express.net;

    root /var/www/colis-express/html;
    index index.html;

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

Décortiquons. listen 80; (et sa variante IPv6 [::]:80) dit d’écouter le trafic HTTP. server_name liste les noms de domaine que ce bloc gère — c’est lui que Nginx compare à l’en-tête Host de chaque requête. root indique le répertoire racine des fichiers. index désigne le fichier servi par défaut quand on demande un répertoire. Enfin, le location / avec try_files $uri $uri/ =404; est une formule canonique : « cherche le fichier demandé, sinon le dossier correspondant, sinon renvoie une vraie 404 ». Sans ce garde-fou, une URL inexistante pourrait produire un comportement inattendu.

Étape 5 — Activer le site et recharger

Le fichier existe mais Nginx l’ignore encore : il faut l’activer en créant le lien symbolique vers sites-enabled/. On en profite pour désactiver le site par défaut, qui sinon capterait les requêtes en premier.

sudo ln -s /etc/nginx/sites-available/colis-express /etc/nginx/sites-enabled/
sudo rm /etc/nginx/sites-enabled/default
sudo nginx -t
sudo systemctl reload nginx

L’étape nginx -t est la plus importante de tout ce parcours : elle teste la configuration avant de l’appliquer. Vous devez voir syntax is ok puis test is successful. Ne lancez jamais un reload sans ce test : une accolade oubliée et c’est tout le serveur qui refuse de redémarrer. Le reload, lui, recharge la configuration en douceur, sans couper les connexions en cours. Ouvrez maintenant http://colis-express.net : la page « Colis Express » s’affiche.

✅ Point d’étape — nginx -t renvoie test is successful et votre domaine affiche la page d’accueil. Si vous voyez encore la page « Welcome to nginx », c’est que le site default n’a pas été désactivé ou que le DNS n’a pas fini de se propager.

Étape 6 — Héberger un second domaine

Tout l’intérêt des vhosts est là : ajouter un site ne demande qu’un nouveau bloc server, pas une nouvelle machine. Démontrons-le avec un second domaine, par exemple un site vitrine séparé.

sudo mkdir -p /var/www/vitrine/html
echo '<h1>Site vitrine</h1>' | sudo tee /var/www/vitrine/html/index.html
sudo chown -R www-data:www-data /var/www/vitrine
sudo nano /etc/nginx/sites-available/vitrine

Avec un contenu calqué sur le premier, en changeant le server_name et le root :

server {
    listen 80;
    listen [::]:80;
    server_name vitrine.example.org;
    root /var/www/vitrine/html;
    index index.html;
    location / { try_files $uri $uri/ =404; }
}

Puis on l’active et on recharge, comme précédemment :

sudo ln -s /etc/nginx/sites-available/vitrine /etc/nginx/sites-enabled/
sudo nginx -t && sudo systemctl reload nginx

Désormais, les deux domaines pointent vers la même IP, mais Nginx sert un contenu différent selon l’en-tête Host. C’est exactement ce qui permet à un hébergeur mutualisé de loger des milliers de sites sur une poignée de serveurs. Le && dans la dernière commande est une astuce utile : il n’enchaîne le reload que si nginx -t a réussi.

✅ Point d’étape — Les deux domaines affichent chacun leur propre page. Vous venez de faire du virtual hosting.

🐞 Pièges fréquents

🌍 Adaptation au contexte ouest-africain

La propagation DNS peut prendre plus de temps qu’annoncé selon le registrar et le fournisseur d’accès. Si votre domaine ne répond pas immédiatement après avoir réglé l’enregistrement A, ne touchez pas à Nginx en boucle : testez d’abord avec l’IP brute (curl -H "Host: colis-express.net" http://VOTRE_IP) pour isoler le problème. Cette commande envoie le bon en-tête Host sans dépendre du DNS, et vous dit en une seconde si Nginx, lui, fait bien son travail. Côté pare-feu, sur les VPS d’entrée de gamme, ufw est souvent déjà présent : pensez à autoriser SSH (ufw allow OpenSSH) avant de l’activer, faute de quoi vous risquez de vous verrouiller dehors.

✅ Récapitulatif

Vous êtes parti d’un serveur nu et vous avez maintenant Nginx installé, un site statique servi sur votre domaine, et un second site cohabitant sur la même machine. Surtout, vous tenez le réflexe qui sous-tend tout le reste : écrire la configuration dans sites-available/, l’activer par lien symbolique, valider avec nginx -t, recharger en douceur. C’est la boucle que vous répéterez à chaque tutoriel suivant. La prochaine étape consiste à ne plus seulement servir des fichiers, mais à relayer vers une vraie application.

🧾 Aide-mémoire

💪 À vous de jouer

Ajoutez une redirection : faites en sorte que www.colis-express.net renvoie une redirection permanente vers colis-express.net (sans www), au lieu de servir le même contenu sous deux adresses.

server {
    listen 80;
    server_name www.colis-express.net;
    return 301 http://colis-express.net$request_uri;
}

Tutoriels frères

• Mettre une API Node.js derrière un reverse proxy Nginx — l’étape suivante : relayer vers une application.
• Durcir Nginx : sécurité TLS, en-têtes et rate limiting — verrouiller le serveur une fois les sites en place.

Pour aller plus loin

• 🔝 Retour au guide principal : Nginx : reverse proxy, HTTPS et configuration de A à Z
• Documentation officielle : Nginx Beginner’s Guide
• Étape suivante du parcours : mettre une API Node.js derrière Nginx.

FAQ

Quelle différence entre reload et restart ?
reload recharge la configuration sans interrompre les connexions en cours : le site ne tombe jamais. restart arrête puis relance le service, ce qui coupe brièvement tout. En production, on privilégie reload.

Dois-je utiliser sites-available ou conf.d ?
Les deux fonctionnent. La paire sites-available/sites-enabled est la convention Debian/Ubuntu et facilite l’activation/désactivation. conf.d/ est la convention des paquets nginx.org et de nombreuses autres distributions. L’essentiel est de rester cohérent.

Puis-je tester sans nom de domaine ?
Oui : remplacez temporairement server_name par _ (joker) pour que le bloc réponde à toute requête, et accédez au site par l’IP du serveur. C’est pratique pour valider avant de brancher le DNS.