Installer et configurer Nginx sur Ubuntu comme reverse proxy simple et maintenable

Résumé express

• Objectif : installer Nginx sur Ubuntu et l’utiliser comme reverse proxy simple.
• Méthode retenue : installation par APT, puis configuration d’un site dédié dans Nginx.
• Vérification attendue : nginx -t, test HTTP local, puis rechargement du service.
• Cas d’usage : exposer proprement une application locale sans publier directement le service applicatif.

Pourquoi Nginx est utile dans ce scénario

Nginx peut jouer deux rôles proches mais distincts : serveur web pour des fichiers statiques, ou reverse proxy devant une application qui tourne ailleurs. Dans ce tutoriel, on retient le second cas, parce qu’il correspond bien aux usages homelab et auto-hébergement : un service applicatif écoute sur une boucle locale ou un port interne, et Nginx reçoit les requêtes entrantes, applique un nom d’hôte, puis les relaye vers l’application cible.

Ce montage reste intéressant quand on veut centraliser l’accès HTTP, garder une configuration lisible et éviter de mélanger la logique réseau avec la logique applicative. Le serveur web reste léger, documenté, et suffisamment souple pour gérer plus tard du TLS, plusieurs hôtes virtuels ou des règles d’acheminement plus fines.

• Un point d’entrée unique pour plusieurs services.
• Une configuration séparée de l’application elle-même.
• Une base simple à faire évoluer sans repartir de zéro.

Méthode retenue et périmètre

La méthode retenue est volontairement sobre : installation du paquet Nginx sur Ubuntu, création d’un bloc serveur dédié, puis proxy_pass vers une application locale. On ne mélange pas ici plusieurs approches d’installation ni plusieurs architectures de déploiement. Si vous avez déjà Apache ou un autre frontal, il faut d’abord clarifier le rôle de chacun avant d’empiler les services.

Cette ligne de conduite a un avantage concret : la configuration reste facile à reprendre plus tard, même si l’application backend change. Seule la cible du proxy évolue, pas la logique du frontal.

Prérequis utiles avant de commencer

Avant d’installer Nginx, il vaut mieux vérifier trois points simples : disposer d’un accès administrateur, connaître le port local de l’application à relayer, et savoir quel nom d’hôte doit pointer vers le serveur. Cela évite les ajustements flous une fois la configuration en place.

• Une machine Ubuntu à jour.
• Des droits sudo.
• Une application locale déjà accessible sur un port connu, par exemple en 127.0.0.1.
• Un nom de serveur ou de domaine de test pour le server_name.

Installer Nginx sur Ubuntu

Sur Ubuntu, la méthode la plus simple et la plus maintenable passe par le dépôt standard et le gestionnaire de paquets APT. Cela donne une installation cohérente avec le reste du système et intégrée à systemd.

sudo apt update
sudo apt install nginx
sudo systemctl enable --now nginx
sudo systemctl status nginx --no-pager

À ce stade, Nginx doit être actif. Si le pare-feu est utilisé sur la machine, il faudra ensuite autoriser le trafic HTTP ou HTTPS selon votre exposition réelle. Ce point dépend de votre politique réseau, donc il vaut mieux le traiter explicitement plutôt que de l’ignorer.

Configurer un reverse proxy simple et lisible

Pour garder une configuration maintenable, le plus propre est de créer un fichier dédié dans sites-available, puis de l’activer via sites-enabled. Ainsi, chaque service exposé possède sa propre définition et ne se mélange pas avec la configuration par défaut.

L’exemple ci-dessous suppose qu’une application écoute localement sur le port 8080. Adaptez uniquement le port et le nom d’hôte à votre contexte.

Exemple de bloc server

server {
    listen 80;
    server_name example.local;

    location / {
        proxy_pass http://127.0.0.1:8080;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

Ce bloc fait trois choses utiles. D’abord, server_name permet d’identifier le site concerné. Ensuite, proxy_pass indique la cible locale. Enfin, les en-têtes transmis à l’application conservent les informations utiles sur la requête d’origine, ce qui évite de perdre le contexte côté backend.

sudo ln -s /etc/nginx/sites-available/example.conf /etc/nginx/sites-enabled/example.conf

Vérifier la configuration avant le rechargement

La vraie vérification ne consiste pas seulement à relire le fichier. Il faut valider la syntaxe, tester le routage et confirmer que Nginx sert bien le bon site. C’est là que nginx -t devient indispensable : il permet d’attraper une erreur de syntaxe ou un bloc mal fermé avant de toucher au service en production.

sudo nginx -t
sudo systemctl reload nginx
curl -I http://127.0.0.1
curl -I -H 'Host: example.local' http://127.0.0.1

• nginx -t confirme que la configuration est syntaxiquement valide.
• systemctl reload nginx applique les changements sans arrêt complet du service.
• curl permet de vérifier la réponse HTTP et le bon choix du server_name.
• Si le backend répond mal, consultez les journaux Nginx et ceux de l’application.

Si la commande curl retourne une réponse attendue, vous avez déjà une preuve concrète que le frontal fonctionne et qu’il relaie correctement la requête. C’est plus utile qu’un simple “service actif” dans systemctl.

Limites, pièges et points d’attention

• Oublier server_name conduit souvent à tomber sur le site par défaut au lieu du bon bloc serveur.
• Une erreur dans proxy_pass ou dans le port local casse le routage même si Nginx démarre correctement.
• Les en-têtes proxy sont utiles : sans eux, certaines applications perdent le contexte de la requête d’origine.
• Le rechargement ne corrige pas une configuration incohérente : il faut toujours passer par nginx -t’avant.
• Pour une exposition réelle sur Internet, il faudra ensuite traiter le TLS, les redirections et les règles de pare-feu.

Le point clé à retenir est simple : Nginx peut rester très propre, à condition de ne pas le surcharger trop tôt. Un bloc serveur par service, une cible locale claire, une validation systématique et un rechargement maîtrisé donnent une base solide pour la suite.

FAQ

Faut-il désactiver le site par défaut ?

Si le site par défaut entre en conflit avec votre propre server_name, oui, il est souvent préférable de le désactiver. Le but est d’éviter les réponses inattendues quand plusieurs blocs serveur écoutent sur le même port.

Nginx sert-il seulement pour le reverse proxy ?

Non. Nginx peut aussi servir des fichiers statiques directement. Mais pour un usage homelab ou auto-hébergement, le reverse proxy reste souvent la fonction la plus utile, car il sépare l’exposition HTTP de l’application elle-même.

Quand faut-il ajouter HTTPS ?

Dès que le service sort du réseau de test ou transporte des identifiants, il faut prévoir HTTPS. Le plus important est d’abord de valider le proxy en HTTP local, puis d’ajouter TLS sans changer la logique du bloc serveur.

Conclusion

Installer et configurer Nginx sur Ubuntu reste une opération simple si l’on garde une méthode claire : installation par paquet, bloc serveur dédié, proxy_pass vers un backend local, puis vérification avec nginx -t’et curl avant le reload. C’est ce cadre minimal qui rend le montage lisible et durable.

Prochaine étape

Si le proxy répond correctement, l’étape suivante consiste à formaliser le fichier de site, puis à ajouter HTTPS et des règles de durcissement adaptées à votre exposition réelle.

Passez ensuite à une configuration plus complète uniquement si le besoin existe vraiment : journalisation, redirections, certificats et gestion de plusieurs hôtes virtuels.