Reverse proxy : définition, rôle et quel outil choisir

Qu'est-ce qu'un reverse proxy ?

Un reverse proxy (ou proxy inverse) est un serveur intermédiaire placé devant vos serveurs applicatifs : il reçoit les requêtes des clients, les transmet au bon backend, puis renvoie la réponse. Le client ne parle jamais directement à vos serveurs, il ne connaît que le proxy. C'est le portier de votre infrastructure, qui centralise le TLS, le routage, la répartition de charge et la sécurité.

Ce guide donne la définition complète, distingue le reverse proxy du proxy classique et du load balancer, puis vous aide à choisir l'outil (HAProxy, Traefik, Nginx, Caddy, Apache, ou un reverse proxy tunnelisé) selon votre contexte. Public : débutants et intermédiaires qui administrent une infrastructure web.

Les 3 bénéfices immédiats :

1. Vos serveurs sont cachés : les utilisateurs ne connaissent que l'adresse du proxy, jamais celle des backends.
2. Un seul point de configuration : certificats TLS, règles de sécurité et logs sont centralisés au même endroit.
3. Haute disponibilité : si un serveur tombe, le proxy redirige automatiquement vers les autres.

L'essentiel

Sans reverse proxy, chaque serveur est exposé directement sur Internet. Avec un reverse proxy, vous avez un point d'entrée unique où vous appliquez toutes vos règles, une seule fois.

Reverse proxy ou proxy : ne pas confondre

Le mot proxy seul désigne en général un forward proxy, qui agit pour le compte des clients : il sort du réseau vers Internet (filtrage web, cache de navigation, anonymisation). Le reverse proxy fait l'inverse, il agit pour le compte des serveurs et reçoit le trafic entrant.

	Proxy (forward)	Reverse proxy (proxy inverse)
Agit pour	les clients (sortie)	les serveurs (entrée)
Cache	qui accède à Internet	quels serveurs répondent
Cas d'usage	filtrage, cache navigation	TLS, routage, load balancing, WAF

Glissez pour voir

Retenez la règle simple : un forward proxy protège et cache les utilisateurs, un reverse proxy protège et cache les serveurs.

Le trajet d'une requête

Quand un utilisateur tape https://app.example.com dans son navigateur, le reverse proxy orchestre tout le parcours avant que la requête n'atteigne votre application.

Étape par étape :

1. Le client appelle https://app.example.com.
2. Le reverse proxy termine le TLS (déchiffre la connexion HTTPS).
3. Il choisit un backend selon ses règles (load balancing + health checks).
4. Il transmet la requête au backend sélectionné.
5. Le backend traite et renvoie la réponse.
6. Le proxy renvoie la réponse au client.

Exemple concret : routage par chemin

Imaginons un site avec trois composants. Le reverse proxy lit l'URL et envoie chaque requête vers le bon serveur :

Requête	Où ça va	Pourquoi
GET /api/users	Backend API (Node.js)	Logique métier
GET /	Frontend (React/Vue)	Interface utilisateur
GET /static/logo.png	Serveur de fichiers ou cache	Performance

Glissez pour voir

Sans reverse proxy, il faudrait trois domaines différents ou tout empiler sur un seul serveur.

Les 5 fonctions clés

Un reverse proxy est un portier qui effectue cinq actions, quel que soit l'outil choisi :

1. Termine le HTTPS : il déchiffre les connexions TLS. Vos backends peuvent tourner en HTTP simple, plus facile à gérer.

2. Route les requêtes : selon le chemin (/api), le domaine (api.example.com) ou un header, il envoie vers le bon backend.

3. Répartit la charge : il distribue les requêtes entre plusieurs serveurs (round-robin, moins de connexions, etc.).

4. Vérifie la santé : il teste régulièrement chaque backend. Un serveur qui ne répond plus est retiré automatiquement.

5. Protège l'accès : rate limiting, blocage d'IP, validation de headers. C'est votre première ligne de défense.

Ce qu'un reverse proxy ne fait PAS

Un reverse proxy aide à filtrer le trafic, mais il ne protège pas contre les attaques DDoS volumétriques. Pour ça, il faut un service anti-DDoS (Cloudflare, AWS Shield) ou un CDN avec scrubbing.

Reverse proxy ou load balancer : quelle différence ?

Ces deux termes sont souvent confondus. Un reverse proxy est un point d'entrée HTTP(S) qui fait du TLS, du routage et de la sécurité. Un load balancer répartit le trafic entre plusieurs serveurs, au niveau transport (L4) ou applicatif (L7).

Concept	Ce qu'il fait	Exemples
Reverse proxy	Point d'entrée HTTP(S) : TLS, routage, headers, sécurité	Nginx, Traefik, Apache
Load balancer	Répartit le trafic entre serveurs (L4 ou L7)	HAProxy, AWS ALB, F5

Glissez pour voir

En pratique, la plupart des outils font les deux. HAProxy est un excellent load balancer qui fait aussi reverse proxy. Nginx est un serveur web, un reverse proxy et un load balancer. Traefik combine tout dans un contexte cloud-native.

L4 contre L7

• L4 (transport) : routage basé sur IP/port, sans regarder le contenu HTTP.
• L7 (application) : routage basé sur l'URL, les headers, les cookies.

HAProxy excelle en L4 et L7. Nginx et Traefik sont principalement L7.

Les familles d'outils

Ces outils n'appartiennent pas à la même catégorie. Comprendre leur famille évite de croire qu'ils font tous la même chose :

Famille	Outils	Spécialité
Load balancer L4/L7	HAProxy	Répartition de charge, haute dispo, checks avancés
Edge proxy cloud-native	Traefik	Découverte de services, config dynamique, conteneurs
Serveur web + reverse proxy	Nginx, Apache, Caddy	Servir du contenu statique + proxy vers backends
Reverse proxy tunnelisé / zero-trust	Pangolin, cloudflared	Publier un service sans ouvrir de port, identité au bord
WAF / reverse proxy filtrant	BunkerWeb	Pare-feu applicatif intégré au proxy
Data-plane / service mesh	Envoy	Proxy L7 à grande échelle (via Istio)

Glissez pour voir

Kubernetes : Ingress contre Service Mesh

• Ingress Controller (Traefik, Nginx) = trafic north-south (client vers cluster).
• Service mesh (Istio/Envoy) = trafic east-west (service vers service) + mTLS, tracing.

Envoy n'est pas un Ingress Controller : c'est le data-plane d'un mesh.

Le reverse proxy tunnelisé, une famille montante

Une nouvelle génération d'outils publie un service sans ouvrir aucun port entrant sur votre pare-feu. Un connecteur ouvre un tunnel sortant vers un point d'entrée public, et le trafic redescend par ce tunnel. C'est idéal pour un homelab derrière une box ou un réseau sans IP publique. Pangolin est l'option auto-hébergée et souveraine, cloudflared l'option managée par Cloudflare. Ces outils sont à double tranchant : la même mécanique sert aussi les attaquants, à surveiller.

Choisir en 5 questions

Répondez à ces questions dans l'ordre. Dès que vous avez un « oui », vous avez votre outil :

Question	Si oui →
1. Kubernetes ou Docker avec découverte auto ?	Traefik, config dynamique par labels/annotations
2. Load balancing L4/L7 critique + health checks avancés ?	HAProxy, conçu pour ça, très stable
3. Servir du web + cache + reverse proxy classique ?	Nginx, le standard, cache intégré
4. HTTPS auto + configuration minimaliste ?	Caddy, Let's Encrypt natif
5. Exposer un service sans ouvrir de port (homelab) ?	Pangolin ou cloudflared

Glissez pour voir

Arbre de décision visuel

Vous exposez un service sans IP publique / sans ouvrir de port ?
├── Oui → Pangolin (auto-hébergé) ou cloudflared (managé)
└── Non → Suite...
    │
    └── Votre infrastructure utilise Kubernetes ?
        ├── Oui → Traefik (IngressRoute) ou Nginx Ingress
        └── Non → Suite...
            │
            └── Docker avec déploiements fréquents ?
                ├── Oui → Traefik (découverte automatique)
                └── Non → Suite...
                    │
                    └── Load balancing L4/L7 avancé ?
                        ├── Oui → HAProxy (health checks, runtime API)
                        └── Non → Nginx (web + cache) ou Caddy (HTTPS auto)

Règle empirique

• Conteneurs / K8s → Traefik
• VM/bare metal + LB avancé → HAProxy
• VM/bare metal + web + cache → Nginx
• Simplicité + auto TLS → Caddy
• Homelab sans port ouvert → Pangolin ou cloudflared
• Pare-feu applicatif intégré → BunkerWeb

Comparatif technique

Ce tableau compare les modèles d'exploitation, pas les performances brutes (suffisantes pour la majorité des charges) :

Critère	HAProxy	Traefik	Nginx	Apache	Caddy
Modèle	LB + proxy L4/L7	Edge proxy cloud-native	Serveur web + proxy	Serveur web	Serveur web moderne
Configuration	Fichier + runtime API	Dynamique (providers)	Fichier	Fichier	Caddyfile
Découverte de services	Non	Docker, K8s, Consul	Non	Non	Non
TLS / ACME	À intégrer	Intégré	À intégrer	À intégrer	Intégré
Cache web	Pas l'objectif	Limité (plugins)	Fort	Correct	Limité
L4 (TCP/UDP)	Excellent	Bon	Bon	Limité	Limité
Quand le choisir	API critiques, LB	Conteneurs, K8s	Web + cache	Legacy, modules	Simplicité

Glissez pour voir

Les deux comparaisons les plus recherchées se résument ainsi. Traefik contre Nginx : Traefik gagne dès qu'il y a des conteneurs (découverte et config dynamique), Nginx reste devant pour servir du contenu web et gérer un cache performant. HAProxy contre Nginx : HAProxy est le meilleur load balancer (health checks fins, runtime API), Nginx est plus polyvalent (web + proxy + cache).

Cas d'usage détaillés

Site web classique (WordPress, CMS, PHP)

Besoin : servir du contenu avec cache, gérer Let's Encrypt, configuration simple. Solutions : Nginx (standard, cache intégré) ou Caddy (HTTPS automatique, idéal pour débuter).

API REST ou application critique

Besoin : haute disponibilité, health checks précis, latence minimale, sessions persistantes. Solution : HAProxy, conçu pour ça et ayant fait l'objet d'un audit de sécurité commandé par l'ANSSI.

Microservices avec Docker

Besoin : découverte automatique des conteneurs, configuration par labels, déploiements fréquents. Solution : Traefik, avec sa configuration Docker par labels.

Kubernetes

Besoin : Ingress Controller, intégration native, gestion des namespaces. Solution : Traefik comme Ingress Controller (Gateway API, IngressRoute) ou Nginx Ingress.

Homelab ou service sans IP publique

Besoin : publier une application depuis un réseau derrière une box, sans ouvrir de port. Solution : Pangolin en auto-hébergé, ou cloudflared en managé.

Les pièges à éviter

1. Single Point of Failure. Votre reverse proxy devient critique. Prévoyez un second proxy en failover (keepalived, VRRP) ou un load balancer cloud devant vos proxies.

2. Headers X-Forwarded oubliés. Vos backends voient l'IP du proxy, pas celle du client. Configurez X-Forwarded-For (IP réelle) et X-Forwarded-Proto (schéma http/https).

3. Timeouts mal réglés. Un timeout trop court provoque des erreurs 504, trop long bloque les connexions. Règle : timeout proxy > timeout backend.

4. Buffers insuffisants. Les gros uploads échouent si les buffers sont trop petits. Surveillez les erreurs 413 et 502.

5. Host header non validé. Sans liste blanche, un attaquant peut manipuler le header Host. Validez toujours les hôtes autorisés.

Comprendre les erreurs 502 et 504

Ces deux codes viennent presque toujours du reverse proxy, pas du client. Une 502 Bad Gateway signifie que le backend a renvoyé une réponse invalide ou a fermé la connexion : backend planté, mauvais port, TLS mal négocié. Une 504 Gateway Timeout signifie que le backend n'a pas répondu à temps : traitement trop long ou timeout proxy trop court. Le réflexe : vérifier que le backend répond directement, puis ajuster les timeouts et les buffers.

Architecture type

Voici une architecture de production classique combinant load balancer cloud, HAProxy en actif/passif et Traefik pour la partie Kubernetes :

Aller plus loin avec Traefik

Traefik est l'outil le plus adapté aux conteneurs et concentre la majeure partie du sous-jacent de cette section. Le parcours complet couvre l'installation, la configuration Docker et Kubernetes, les certificats, les middlewares, la sécurité et l'observabilité :

Installer Traefik v3 Binaire, Docker et package manager.

Traefik avec Docker Labels, réseaux et exemples pratiques.

TLS et ACME Let's Encrypt et certificats automatiques.

Middlewares Transformer et sécuriser les requêtes.

Questions fréquentes

Reverse proxy, c'est quoi en une phrase ?

Un reverse proxy est un serveur qui reçoit les requêtes des clients à la place de vos serveurs applicatifs, puis les transmet au bon backend et renvoie la réponse. Il centralise le TLS, le routage et la sécurité.

À quoi sert un reverse proxy ?

À cacher et protéger vos serveurs derrière un point d'entrée unique, terminer le HTTPS, répartir la charge entre plusieurs backends, et appliquer des règles de sécurité (rate limiting, filtrage) au même endroit.

Quel est le meilleur reverse proxy open source ?

Il n'y a pas de gagnant universel. Traefik pour les conteneurs et Kubernetes, HAProxy pour le load balancing critique, Nginx pour le web et le cache, Caddy pour la simplicité et le HTTPS automatique. Tous sont open source.

Comment faire un reverse proxy HTTPS ?

Le proxy termine le TLS avec un certificat, souvent obtenu automatiquement via Let's Encrypt (ACME). Traefik et Caddy le font nativement ; Nginx, Apache et HAProxy demandent une intégration (certbot ou équivalent).

Peut-on faire un reverse proxy sans ouvrir de port ?

Oui, avec un reverse proxy tunnelisé comme Pangolin ou cloudflared : un connecteur ouvre un tunnel sortant et le trafic redescend, sans exposer de port entrant sur votre réseau.

À retenir

1. Un reverse proxy est le point d'entrée unique de votre infrastructure : TLS, routage et sécurité centralisés.

2. Proxy et reverse proxy sont opposés : le premier agit pour les clients, le second pour les serveurs.

3. Il fait 5 choses : termine le TLS, route, répartit, vérifie la santé, protège.

4. Choisissez selon votre écosystème : Traefik pour conteneurs, HAProxy pour LB critique, Nginx pour web + cache, Caddy pour la simplicité, Pangolin/cloudflared pour un homelab sans port ouvert.

5. Prévoyez la haute disponibilité du proxy lui-même : il devient votre nouveau point de défaillance unique.

Prochaines étapes

Traefik : reverse proxy cloud-native Concepts, providers, routeurs et services. Idéal pour Docker et Kubernetes.

HAProxy : load balancing et haute dispo Configuration, health checks, TLS, rate limiting.

Nginx : serveur web et reverse proxy proxy_pass, cache, load balancing, TLS.

Caddy : HTTPS automatique Caddyfile, Let's Encrypt intégré, reverse proxy simple.

Pangolin : tunnel self-hosted Exposer un service sans ouvrir de port, plan de contrôle chez vous.

BunkerWeb : reverse proxy WAF Un pare-feu applicatif intégré au reverse proxy.

×

📖 Voir la documentation →