Accueil

Reverse Proxy : Apache, Nginx, ou Traefik

Web
Difficulte: Intermediate
4 min de lecture

Tutoriel détaillé pour configurer un reverse proxy avec Apache, Nginx ou Traefik sur Linux pour optimiser et sécuriser votre infrastructure.

Retour aux tutoriels

L'essentiel

  • Un reverse proxy est le point d'entrée unique placé devant vos serveurs applicatifs : il apporte la répartition de charge, la terminaison SSL, la mise en cache, le routage par URL et masque les backends. Il reste totalement transparent pour le client.
  • Côté Nginx, tout tient dans une directive proxy_pass http://127.0.0.1:3000; à l'intérieur d'un bloc location. Le fichier se crée dans sites-available, s'active par un lien symbolique vers sites-enabled, se valide avec nginx -t puis s'applique avec systemctl reload nginx.
  • Les quatre en-têtes Host, X-Real-IP, X-Forwarded-For et X-Forwarded-Proto ne sont pas décoratifs : sans eux, l'application backend voit toutes les requêtes venir du proxy et croit être servie en HTTP.
  • Avec Apache, il faut d'abord activer les modules (a2enmod proxy, a2enmod proxy_http) et redémarrer, avant de déclarer ProxyPreserveHost On, ProxyPass et ProxyPassReverse dans le VirtualHost.
  • Traefik se passe de fichier de routes : il lit les labels des conteneurs via le socket /var/run/docker.sock monté en lecture seule et crée les routes dynamiquement au démarrage de chaque conteneur. Pour le HTTPS, Nginx et Apache passent par certbot ; Traefik obtient et renouvelle les certificats lui-même.
Qu'est-ce qu'un Reverse Proxy ?
Un reverse proxy est un serveur qui se situe devant un ou plusieurs serveurs web. Il intercepte les requêtes des clients et les transmet aux serveurs appropriés en backend. Pour le client, le reverse proxy est totalement transparent, il semble être le serveur web final.

Pourquoi utiliser un Reverse Proxy ?

  • Répartition de charge (Load Balancing) : Distribue le trafic sur plusieurs serveurs backend pour éviter la surcharge et améliorer la disponibilité.
  • Sécurité : Masque l'identité et les caractéristiques des serveurs backend. Il peut aussi filtrer les requêtes malveillantes.
  • Centralisation du SSL/TLS : Gère le déchiffrement HTTPS en un seul point (SSL Termination), simplifiant la gestion des certificats.
  • Mise en cache : Peut mettre en cache le contenu statique pour accélérer les temps de réponse et soulager les serveurs backend.
  • Routage basé sur l'URL : Peut diriger `domaine.com/api` vers un service et `domaine.com/blog` vers un autre.

Choisir son outil

  • Nginx : Le choix le plus populaire. Extrêmement performant, léger, et sa configuration en reverse proxy est très simple. Idéal pour la plupart des cas d'usage.
  • Apache : Très puissant et flexible grâce à ses nombreux modules (mod_proxy), mais sa configuration peut être plus verbeuse. Un bon choix si vous êtes déjà dans un écosystème Apache.
  • Traefik : L'outil moderne par excellence pour les environnements basés sur des conteneurs (Docker, Kubernetes). Il se configure dynamiquement en détectant les conteneurs qui démarrent.

Configuration avec Nginx (Recommandé)

C'est le cas le plus courant et souvent le plus simple.

Étape 1 : Installer Nginx

sudo apt-get update
sudo apt-get install -y nginx

Étape 2 : Créer un fichier de configuration

Créez un fichier dans /etc/nginx/sites-available/mon-proxy :

server {
    listen 80;
    server_name votre-domaine.com;

    location / {
        # L'adresse de votre service backend
        proxy_pass http://127.0.0.1:3000; 

        # En-têtes à transmettre
        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;
    }
}

Étape 3 : Activer le site et recharger Nginx

sudo ln -s /etc/nginx/sites-available/mon-proxy /etc/nginx/sites-enabled/
sudo nginx -t # Vérifier la syntaxe
sudo systemctl reload nginx

Toutes les requêtes arrivant sur `votre-domaine.com` seront maintenant transmises à l'application qui tourne sur le port 3000 de la même machine.

Configuration avec Traefik et Docker (Moderne)

Idéal si vos applications tournent dans des conteneurs Docker.

Étape 1 : Créer le fichier `docker-compose.yml`

version: "3.3"

services:
  traefik:
    image: "traefik:v2.9"
    command:
      - "--api.insecure=true"
      - "--providers.docker=true"
      - "--entrypoints.web.address=:80"
    ports:
      - "80:80"
      - "8080:8080" # Interface de Traefik
    volumes:
      - "/var/run/docker.sock:/var/run/docker.sock:ro"

  mon-app:
    image: "containous/whoami" # Une image simple qui affiche des infos sur la requête
    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.mon-app.rule=Host(`votre-domaine.com`)"
      - "traefik.http.routers.mon-app.entrypoints=web"

Étape 2 : Lancer les services

docker-compose up -d

C'est tout ! Traefik a automatiquement détecté le conteneur `mon-app` grâce à ses labels et a créé la route. Si vous lancez d'autres conteneurs avec des labels similaires, Traefik les ajoutera dynamiquement.

Configuration avec Apache (mod_proxy)

Étape 1 : Activer les modules nécessaires

sudo a2enmod proxy
sudo a2enmod proxy_http
sudo systemctl restart apache2

Étape 2 : Configurer un VirtualHost

Modifiez votre fichier de configuration de site (ex: /etc/apache2/sites-available/000-default.conf).


<VirtualHost *:80>
    ServerName votre-domaine.com

    ProxyPreserveHost On
    ProxyPass / http://127.0.0.1:3000/
    ProxyPassReverse / http://127.0.0.1:3000/
</VirtualHost>

Étape 3 : Recharger Apache

sudo systemctl reload apache2
Et le HTTPS ?
L'étape suivante pour un reverse proxy de production est d'activer le HTTPS. Avec Nginx et Apache, vous pouvez utiliser certbot de Let's Encrypt. Avec Traefik, c'est encore plus simple : il suffit d'ajouter quelques lignes à sa configuration pour qu'il obtienne et renouvelle les certificats automatiquement.

Conclusion

Le reverse proxy est un composant fondamental de l'architecture web moderne. Il apporte sécurité, performance et flexibilité. - Nginx est le choix polyvalent et performant pour des déploiements classiques. - Traefik est le roi de l'automatisation dans les environnements conteneurisés. - Apache reste une option viable, surtout si votre infrastructure existante repose déjà sur lui. Le choix dépend de votre architecture, mais la mise en place d'un reverse proxy est presque toujours une bonne décision.

MR

Écrit par

Morgann Riu

Expert en cybersécurité et administration Linux. Je partage mes connaissances à travers des tutoriels gratuits et des formations pour aider les administrateurs systèmes et développeurs à sécuriser leurs infrastructures.

Questions fréquentes

Pourquoi mon application backend voit-elle toutes les requêtes venir de 127.0.0.1 ?
Parce que du point de vue du backend, le client c'est le proxy. L'adresse réelle du visiteur doit être transmise explicitement dans un en-tête : proxy_set_header X-Real-IP $remote_addr; et proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; côté Nginx, ou ProxyPreserveHost On côté Apache pour le nom d'hôte. Il faut ensuite configurer l'application ou son framework pour qu'il fasse confiance à ces en-têtes, sinon les journaux continueront d'afficher l'adresse du proxy.
Nginx, Apache ou Traefik : lequel choisir ?
Nginx est le choix par défaut pour un déploiement classique : très performant, léger, et sa configuration en reverse proxy tient en quelques lignes. Traefik s'impose dès que les applications tournent en conteneurs Docker ou sur Kubernetes, puisqu'il détecte les conteneurs au démarrage et construit les routes tout seul à partir de leurs labels. Apache reste pertinent si votre infrastructure repose déjà dessus : mod_proxy fait le même travail, avec une configuration plus verbeuse.
À quoi sert ProxyPassReverse si ProxyPass fait déjà suivre les requêtes ?
ProxyPass gère l'aller : il transmet la requête entrante au backend. ProxyPassReverse gère le retour : il réécrit les en-têtes de redirection émis par le backend pour qu'ils pointent vers l'URL publique et non vers http://127.0.0.1:3000/. Sans cette seconde directive, la moindre redirection applicative renvoie le navigateur du visiteur vers une adresse interne injoignable. Les deux vont toujours par paire.
Ma configuration Nginx n'est pas prise en compte, qu'ai-je oublié ?
Un fichier déposé dans /etc/nginx/sites-available/ n'est jamais lu tant qu'il n'est pas activé : il faut créer le lien symbolique vers /etc/nginx/sites-enabled/. Validez ensuite systématiquement la syntaxe avec nginx -t avant de recharger, car un rechargement sur une configuration invalide échoue et vous laisse silencieusement avec l'ancienne. Terminez par systemctl reload nginx, qui applique les changements sans couper les connexions en cours.
Le certificat HTTPS doit-il être installé sur le proxy ou sur le backend ?
Sur le proxy : c'est tout l'intérêt de la terminaison SSL. Le déchiffrement se fait en un seul point, vous n'avez qu'un jeu de certificats à gérer et à renouveler, et les backends restent en HTTP simple sur 127.0.0.1. Pensez seulement à transmettre proxy_set_header X-Forwarded-Proto $scheme; pour que l'application sache que la requête d'origine était chiffrée et ne génère pas des liens en http. Avec Nginx et Apache, certbot fait le travail ; Traefik gère obtention et renouvellement automatiquement.

Partager ce tutoriel

Cet article vous a plu ?

Cet article vous a-t-il été utile ?

Merci pour votre retour !

Commentaires

Recommandé pour vous

Article de fond sur le sujet

Checklist Sécurité Linux

30 points essentiels pour sécuriser un serveur Linux. Recevez aussi les nouveaux tutoriels par email.

Pas de spam. Désabonnement en 1 clic.