Un reverse proxy est un serveur intermédiaire placé devant les serveurs backend. Il reçoit les requêtes des clients et les transmet au(x) serveur(s) approprié(s), puis renvoie la réponse au client. Du point de vue du client, il communique toujours avec un seul point d’entrée.

À ne pas confondre avec le forward proxy (mandataire sortant) qui masque l’identité du client — le reverse proxy masque l’identité du serveur.


Forward Proxy vs Reverse Proxy

Forward ProxyReverse Proxy
Positionné devantLe clientLe serveur
MasqueL’identité du clientL’identité du serveur
Usage typiqueContrôle d’accès sortant, cache navigateur, contournement de restrictionsExposition sécurisée de services internes, TLS, routage
ExemplesSquid, Privoxy, VPNNGINX, HAProxy, Traefik, Caddy

Fonctionnement

Client
  │  requête vers exemple.com
  ▼
[ Reverse Proxy ]   ← point d'entrée unique
  ├── /api    → Backend API      (10.0.1.10:8080)
  ├── /static → Backend CDN      (10.0.1.11:80)
  └── /auth   → Backend Auth     (10.0.1.12:3000)
            ↑
      le client ne connaît jamais ces IPs

Fonctionnalités principales

FonctionnalitéDescription
Routage (path/host)Redirige selon l’URL ou le header Host (/api → service A, /app → service B)
Terminaison TLSDéchiffre le HTTPS entrant, communique en HTTP clair avec les backends (TLS offloading)
Load balancingRépartit la charge entre plusieurs instances du même backend
CacheMet en cache les réponses statiques pour soulager les backends
CompressionCompresse les réponses (gzip/brotli) à la volée
Réécriture d’URLModifie le chemin avant de transmettre au backend
Rate limitingLimite le nombre de requêtes par IP ou par endpoint
WAFFiltre les requêtes malveillantes (injection SQL, XSS…)
AuthentificationCentralise l’auth (Basic Auth, OAuth2 proxy, mTLS)

Exemple : Configuration NGINX (reverse proxy simple)

server {
    listen 80;
    server_name monapp.exemple.com;
 
    # Redirection HTTP → HTTPS
    return 301 https://$host$request_uri;
}
 
server {
    listen 443 ssl;
    server_name monapp.exemple.com;
 
    ssl_certificate     /etc/ssl/certs/monapp.crt;
    ssl_certificate_key /etc/ssl/private/monapp.key;
 
    # Routage par path
    location /api/ {
        proxy_pass http://backend-api:8080/;      # forward vers le backend API
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;  # transmet la vraie IP client
    }
 
    location / {
        proxy_pass http://backend-frontend:80/;
        proxy_set_header Host $host;
    }
}

Exemple : Configuration NGINX avec load balancing

# Définition du pool de backends
upstream api_backends {
    least_conn;                          # algorithme least connections
    server 10.0.1.10:8080 weight=3;
    server 10.0.1.11:8080 weight=1;
    server 10.0.1.12:8080 backup;       # utilisé uniquement si les autres tombent
}
 
server {
    listen 443 ssl;
    server_name api.exemple.com;
 
    location / {
        proxy_pass http://api_backends;
        proxy_connect_timeout 5s;
        proxy_read_timeout 30s;
    }
}

Reverse Proxy vs Load Balancer

Ces deux concepts se recoupent souvent mais ne sont pas identiques :

Reverse ProxyLoad Balancer
Couche OSIL7 (Application)L4 (TCP/UDP) ou L7
Objectif principalRoutage intelligent, sécurité, terminaison TLSRépartition de charge
Connaissance du contenuOui (lit les headers, l’URL, le body)L4 : non / L7 : oui
Cas d’usageAPI gateway, exposition de microservicesHaute disponibilité, scalabilité

Un reverse proxy L7 est souvent aussi un load balancer. La différence tient à l’accent mis sur l’une ou l’autre fonction.


Implémentations courantes

OutilContexte d’usage
NGINXServeur web + reverse proxy généraliste, très répandu
HAProxyHaute performance, TCP/HTTP, très utilisé en production
TraefikCloud-native, auto-découverte Docker/Kubernetes
CaddyTLS automatique intégré (Let’s Encrypt natif)
ingress-nginxReverse proxy NGINX dans Kubernetes (Ingress Controller)
AWS ALBReverse proxy managé L7 sur AWS
EnvoyProxy haute performance, base d’Istio (service mesh)

En relation avec