Reverse proxy : comprendre et choisir le bon outil

En 1 minute : pourquoi un reverse proxy ?

Un reverse proxy est le “portier” de votre infrastructure. Il se place entre vos utilisateurs et vos serveurs, et gère tout ce qui arrive avant que la requête n’atteigne votre application.

Les 3 bénéfices immédiats :

1. Vos serveurs sont cachés — les utilisateurs ne connaissent que l’adresse du proxy, pas celle de vos backends
2. Un seul point de configuration — certificats TLS, règles de sécurité, logs : tout est centralisé
3. Haute disponibilité automatique — si un serveur tombe, le proxy redirige 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.

Le trajet d’une requête (ce qui se passe vraiment)

Quand un utilisateur tape https://app.example.com dans son navigateur, voici ce qui se passe :

É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 votre site avec 3 composants :

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

Le reverse proxy lit l’URL et envoie chaque requête vers le bon serveur. Sans lui, vous auriez besoin de 3 domaines différents ou de tout mettre sur un seul serveur.

Les 5 fonctions clés (ce que fait le proxy)

Un reverse proxy est un “portier” qui effectue 5 actions :

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. Si un serveur ne répond plus, il est retiré automatiquement.

5. Protège l’accès — Rate limiting, blocage d’IPs, 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 (rate limiting, blocage d’IPs), mais il ne protège pas contre les attaques DDoS volumétriques. Pour ça, il faut un service anti-DDoS (Cloudflare, AWS Shield, etc.) ou un CDN avec scrubbing.

Reverse proxy vs Load balancer : quelle différence ?

Ces deux termes sont souvent confondus. Clarifions :

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 plusieurs 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 + reverse proxy + load balancer. Traefik combine tout dans un contexte cloud-native.

L4 vs 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 5 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 pour l’IP réelle
• X-Forwarded-Proto pour le schéma (http/https)

3. Timeouts mal configurés

• Timeout trop court → erreurs 504 intempestives
• Timeout trop long → connexions bloquées
• Règle : proxy timeout > backend timeout

4. Buffer size insuffisant Les gros uploads échouent si les buffers sont trop petits. Surveillez les erreurs 413/502.

5. Host header non validé Sans whitelist, un attaquant peut manipuler le header Host. Toujours valider les hosts autorisés.

Choisir en 5 questions

Répondez à ces questions dans l’ordre. Dès que vous avez une réponse, 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 + config minimaliste ?	Caddy — Let’s Encrypt natif, Caddyfile simple
5. Application legacy / modules PHP ?	Apache — écosystème de modules

Glissez pour voir

Arbre de décision visuel

Votre infrastructure utilise Kubernetes ?
├── Oui → Traefik (IngressRoute) ou Nginx Ingress
└── Non → Suite...
    │
    └── Vous utilisez Docker avec déploiements fréquents ?
        ├── Oui → Traefik (découverte automatique)
        └── Non → Suite...
            │
            └── Vous avez besoin de load balancing L4/L7 avancé ?
                ├── Oui → HAProxy (health checks précis, runtime API)
                └── Non → Suite...
                    │
                    └── Vous voulez servir du contenu + cache ?
                        ├── Oui → Nginx (web server + proxy + cache)
                        └── Non → Caddy (HTTPS auto, config minimale)

Règle empirique

• Conteneurs / K8s → Traefik
• VM/bare metal + LB avancé → HAProxy
• VM/bare metal + web + cache → Nginx
• Simplicité + auto TLS → Caddy
• Legacy / modules PHP → Apache

Les familles d’outils

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

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
Data-plane / Service mesh	Envoy	Proxy L7 avancé à grande échelle (via Istio)

Glissez pour voir

Kubernetes : Ingress vs Service Mesh

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

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

Cas d’usage détaillés

Site web classique (WordPress, CMS, PHP)

Besoin : servir du contenu avec cache, gérer les certificats Let’s Encrypt, configuration simple.

Solutions recommandées :

• Nginx — Standard de l’industrie, documentation abondante, cache intégré
• Caddy — HTTPS automatique, configuration minimale, idéal pour débuter

API REST / Application critique

Besoin : haute disponibilité, health checks précis, latence minimale, sessions persistantes.

Solutions recommandées :

• HAProxy — Conçu pour ça, audit de sécurité commandé par l’ANSSI, utilisé dans des environnements à très forte charge
• Nginx — Polyvalent, supporte TCP/UDP

Microservices avec Docker

Besoin : découverte automatique des conteneurs, configuration par labels, déploiements fréquents.

Solution recommandée :

• Traefik — Détection automatique, configuration dynamique, Let’s Encrypt intégré

Voir aussi : Traefik avec Docker

Kubernetes

Besoin : Ingress Controller, intégration native, gestion des namespaces.

Solutions recommandées :

• Traefik — IngressRoute CRD, middlewares intégrés → voir Traefik sur Kubernetes
• Nginx Ingress — Le plus répandu, configuration via annotations

Comparaison technique (optionnel)

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

Critère	HAProxy	Traefik	Nginx	Apache	Caddy
Modèle	LB + proxy L4/L7	Edge proxy cloud-native	Serveur web + proxy	Serveur web legacy	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	OK	Limité
L4 (TCP/UDP)	Excellent	Bon	Bon	Limité	Limité
Quand le choisir	API critiques, LB	Conteneurs, K8s	Web + cache	Legacy	Simplicité

Glissez pour voir

Architecture type

Voici une architecture production classique :

À retenir

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

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

3. Choisissez selon votre écosystème : Traefik pour conteneurs, HAProxy pour LB critique, Nginx pour web+cache, Caddy pour simplicité.

4. Les health checks sont essentiels — ils retirent automatiquement les backends défaillants.

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

Guides détaillés par outil

HAProxy : load balancer haute disponibilité Configuration complète, health checks, TLS, rate limiting.

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

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

Apache HTTP Server mod_proxy, mod_proxy_balancer, configuration legacy.

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

×

📖 Voir la documentation →