// Serveur & self-hosting

Reverse proxy avec Nginx : exposer ses services proprement

Par Kévin Papot · publié le 4 mars 2026

Vous avez trois applications qui tournent sur votre serveur : une API sur le port 3000, un tableau de bord sur le 8080, un blog sur le 2368. Comment les rendre accessibles proprement, chacune sur sa propre adresse, en HTTPS, sans que l’utilisateur ait à taper de numéro de port ? La réponse tient en deux mots : reverse proxy. Nginx est l’outil de référence pour ce rôle. Ce guide en explique le principe, détaille une configuration complète et compare Nginx à ses alternatives modernes, Traefik et Caddy.

Reverse proxy : de quoi parle-t-on ?

Un proxy classique (forward proxy) se place devant des clients : il relaie leurs requêtes vers Internet. Un reverse proxy fait l’inverse : il se place devant vos serveurs et reçoit les requêtes des visiteurs pour les distribuer vers le bon service en interne.

Concrètement, tout le trafic entre par un seul point — les ports 80 (HTTP) et 443 (HTTPS) — et Nginx décide, selon le nom de domaine ou le chemin demandé, vers quelle application interne router la requête. Le visiteur ne voit jamais les ports internes ni l’organisation réelle de votre serveur.

Les bénéfices sont nombreux :

  • Un point d’entrée unique pour plusieurs applications.
  • Terminaison TLS centralisée : Nginx gère le HTTPS, vos applications restent en HTTP simple en interne.
  • Répartition de charge entre plusieurs instances d’un même service.
  • Cache, compression et sécurité appliqués en amont, avant même d’atteindre l’application.

Installer Nginx

Sur une distribution Debian ou Ubuntu :

# Installer Nginx
sudo apt update && sudo apt install nginx

# Vérifier que le service tourne
sudo systemctl status nginx

# Tester la validité de la configuration après chaque modification
sudo nginx -t

# Recharger sans couper les connexions en cours
sudo systemctl reload nginx

La configuration vit dans /etc/nginx/. La bonne pratique consiste à créer un fichier par site dans /etc/nginx/sites-available/, puis à l’activer par un lien symbolique vers /etc/nginx/sites-enabled/.

Le cœur du sujet : le server block et proxy_pass

Dans Nginx, chaque site se déclare dans un bloc server. Pour transformer Nginx en reverse proxy, l’instruction clé est proxy_pass, qui transmet la requête vers un service interne.

Voici une configuration complète pour exposer une application qui écoute sur localhost:3000 derrière le domaine app.mondomaine.fr :

server {
    listen 80;
    server_name app.mondomaine.fr;

    location / {
        # Transmettre vers l'application interne
        proxy_pass http://127.0.0.1:3000;

        # Transmettre les en-têtes d'origine à l'application
        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;
    }
}

Les directives proxy_set_header sont essentielles : sans elles, votre application verrait toutes les requêtes provenir de 127.0.0.1 et ignorerait l’adresse IP réelle du visiteur ou le protocole utilisé. X-Forwarded-For transmet l’IP d’origine, X-Forwarded-Proto indique si la connexion initiale était en HTTPS.

Une fois le fichier créé dans sites-available/app.conf, on l’active :

sudo ln -s /etc/nginx/sites-available/app.conf /etc/nginx/sites-enabled/
sudo nginx -t && sudo systemctl reload nginx

Gérer les applications temps réel (WebSocket)

Les applications modernes utilisent souvent des WebSockets (chat en direct, notifications, rechargement à chaud). Nginx a besoin d’instructions supplémentaires pour laisser passer cette mise à niveau de protocole :

location / {
    proxy_pass http://127.0.0.1:3000;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
    proxy_set_header Host $host;
}

Sans ces trois lignes, la connexion WebSocket échouera silencieusement — un grand classique des heures de débogage perdues.

Plusieurs services sur un même serveur

C’est là que le reverse proxy prend tout son sens. Deux stratégies coexistent.

Par sous-domaine (recommandé)

Chaque application obtient son propre server block, distingué par server_name :

server {
    listen 80;
    server_name api.mondomaine.fr;
    location / {
        proxy_pass http://127.0.0.1:3000;
        proxy_set_header Host $host;
    }
}

server {
    listen 80;
    server_name blog.mondomaine.fr;
    location / {
        proxy_pass http://127.0.0.1:2368;
        proxy_set_header Host $host;
    }
}

Nginx lit l’en-tête Host de chaque requête entrante et route vers le bon bloc. C’est propre, lisible et facile à sécuriser individuellement.

Par chemin d’URL

On peut aussi router selon le chemin, sur un même domaine :

server {
    listen 80;
    server_name mondomaine.fr;

    location /api/ {
        proxy_pass http://127.0.0.1:3000/;
        proxy_set_header Host $host;
    }

    location /dashboard/ {
        proxy_pass http://127.0.0.1:8080/;
        proxy_set_header Host $host;
    }
}

Attention au slash final — Dans proxy_pass http://127.0.0.1:3000/;, la présence ou l’absence du / de fin change tout. Avec un slash, Nginx retire le préfixe location (/api/) avant de transmettre ; sans slash, il le conserve. Une source d’erreurs 404 très fréquente : testez toujours le comportement réel.

Ajouter la répartition de charge

Pour distribuer le trafic entre plusieurs instances d’une même application, on déclare un groupe upstream :

upstream mon_app {
    server 127.0.0.1:3000;
    server 127.0.0.1:3001;
    server 127.0.0.1:3002;
}

server {
    listen 80;
    server_name app.mondomaine.fr;
    location / {
        proxy_pass http://mon_app;
        proxy_set_header Host $host;
    }
}

Nginx répartit alors les requêtes entre les trois instances (par défaut en round-robin). C’est la base de la haute disponibilité.

Et le HTTPS ?

Toute cette configuration tourne en HTTP simple, ce qui n’est acceptable qu’en local. En production, le chiffrement est indispensable. Nginx s’intègre parfaitement avec Let’s Encrypt pour obtenir un certificat gratuit : notre guide dédié au certificat SSL avec Let’s Encrypt montre comment Certbot modifie automatiquement vos blocs server pour ajouter la couche TLS.

Nginx, Traefik ou Caddy ?

Nginx n’est pas seul sur le créneau. Deux alternatives modernes valent le détour.

  • Caddy — sa force est la simplicité radicale : il obtient et renouvelle les certificats HTTPS automatiquement, sans configuration. Un Caddyfile de trois lignes suffit à exposer un service en TLS. Idéal pour aller vite.
app.mondomaine.fr {
    reverse_proxy 127.0.0.1:3000
}
  • Traefik — pensé pour les environnements dynamiques (Docker, Kubernetes). Il découvre les services automatiquement grâce à des labels et reconfigure le routage à la volée, sans redémarrage. Incontournable dès qu’on manipule beaucoup de conteneurs.

Nginx conserve l’avantage de la maturité, des performances éprouvées et d’une documentation immense. Pour un serveur avec quelques services stables, il reste le choix par défaut. Pour une pile 100 % Docker, Traefik brille ; pour la simplicité maximale, Caddy gagne.

En résumé

Le reverse proxy Nginx transforme un serveur en un point d’entrée propre et sécurisé pour toutes vos applications. Retenez le trio gagnant : un server block par service, proxy_pass vers le port interne, et les proxy_set_header pour préserver les informations du visiteur. Ajoutez le HTTPS via Let’s Encrypt, et votre infrastructure a l’allure d’un service professionnel.

À lire ensuite