Load Balancer vs Forward Proxy — Comparaison détaillée
Ces deux composants réseau traitent tous les deux du trafic HTTP, ce qui les fait souvent confondre. Pourtant ils ont des rôles, des positions et des objectifs radicalement différents dans une architecture.
Position dans l’architecture
Internet
│
▼
┌──────────────────────────────────────────────────────────────────┐
│ Réseau d'entreprise │
│ │
│ ┌──────────────┐ ┌───────────────────┐ │
│ │ FORWARD │ ← SORTANT │ LOAD BALANCER / │ │
│ │ PROXY │ clients → Internet │ REVERSE PROXY │ │
│ │ (Squid) │ │ (NGINX, ALB) │ │
│ └──────────────┘ └───────────────────┘ │
│ ▲ │ │
│ │ ▼ ENTRANT │
│ Clients internes Backends internes │
│ (PCs, serveurs) (APIs, services) │
└──────────────────────────────────────────────────────────────────┘
Forward Proxy : positionné en sortie du réseau interne
Load Balancer : positionné en entrée devant les serveurs
Tableau comparatif complet
| Critère | Forward Proxy | Load Balancer |
|---|---|---|
| Direction du trafic | Sortant (clients → Internet) | Entrant (Internet → backends) |
| Représente | Les clients auprès d’Internet | L’infrastructure auprès des clients |
| Initié par | Le client (configuré explicitement) | Transparent pour le client |
| Couche OSI | L7 Application | L4 TCP ou L7 Application |
| Répartition de charge | ❌ | ✅ (fonction principale) |
| Health checks | ❌ | ✅ (retire les backends défaillants) |
| Cache | ✅ (économise la bande passante sortante) | ❌ (ou limité) |
| Filtrage URL/domaine | ✅ (blacklist, whitelist) | ❌ |
| Journalisation du trafic sortant | ✅ | ❌ |
| Anonymisation IP clients | ✅ (masque l’IP des clients) | ❌ |
| Terminaison TLS | ✅ (SSL inspection optionnelle) | ✅ (TLS offloading natif) |
| Routage par URL/headers | ❌ | ✅ (L7 LB) |
| Sticky sessions | ❌ | ✅ |
| Authentification | ✅ (accès Internet conditionnel) | Limité |
| Exemples | Squid, mitmproxy, Privoxy | NGINX, HAProxy, AWS ALB/NLB |
Ce que chacun voit dans une requête HTTP
Requête : GET https://github.com/user/repo HTTP/1.1
Forward Proxy voit :
✅ URL complète : https://github.com/user/repo
✅ Headers HTTP : Host, User-Agent, Authorization...
✅ IP source du client : 10.0.1.5
✅ Body (si HTTP, ou si SSL inspection activée)
✅ Domaine de destination : github.com
→ Peut bloquer github.com si dans la blacklist
→ Peut journaliser qui accède à quoi
Load Balancer L4 voit :
✅ IP destination : 93.184.1.10 (IP de github.com)
✅ Port : 443
❌ URL, headers, body (données chiffrées opaques)
→ Distribue le flux TCP vers un backend, c'est tout
Load Balancer L7 voit :
✅ Host header : github.com
✅ URL path : /user/repo
✅ Méthode HTTP : GET
❌ Données chiffrées si HTTPS non terminé
→ Route vers le bon backend selon le path/host
Flux réseau côte à côte
FLUX avec Forward Proxy :
Client (10.0.1.5)
│ Configure proxy : 10.0.0.5:3128
▼
Forward Proxy (Squid)
│ Vérifie les ACLs → github.com autorisé ✅
│ Remplace l'IP source : 10.0.1.5 → 203.0.113.1 (IP publique du proxy)
│ Fait la requête DNS pour github.com
▼
Internet → github.com
│ github.com voit : IP=203.0.113.1 (l'IP du proxy, pas du client)
▼
Réponse → Forward Proxy → Client
FLUX avec Load Balancer :
Client externe (Internet)
│ DNS : api.exemple.com → 52.10.0.1 (IP du LB)
▼
Load Balancer (AWS ALB)
│ Sélectionne Backend 2 (round-robin, 3 backends sains)
│ Termine TLS
│ Ajoute X-Forwarded-For: IP_client
▼
Backend 2 (10.0.1.12:8080)
│ Backend voit : requête HTTP en clair + vraie IP client dans X-Forwarded-For
▼
Réponse → Load Balancer → Client
Cas où on les confond
Confusion 1 — “Le LB cache les IPs comme le proxy”
Forward Proxy : cache l'IP du CLIENT (le client est anonyme côté serveur destination)
Load Balancer : le client connaît l'IP du LB, mais pas celle des backends
→ ce n'est pas la même chose — le LB protège les BACKENDS, pas les clients
Confusion 2 — “Les deux font du routage HTTP”
Forward Proxy : route VERS l'extérieur selon la destination demandée par le client
Load Balancer L7 : route VERS l'intérieur selon l'URL/host pour répartir la charge
Forward Proxy → "où tu veux aller sur Internet ?"
Load Balancer → "quel backend interne doit répondre à cette requête ?"
Confusion 3 — “Les deux terminent TLS”
Forward Proxy (SSL inspection) :
Client → [TLS client-proxy] → Proxy → [nouveau TLS proxy-destination]
Le proxy déchiffre TOUT le trafic → contenu visible → risque vie privée
Nécessite d'installer le certificat CA du proxy sur les clients
Load Balancer (TLS offloading) :
Client → [TLS client-LB] → LB → [HTTP clair ou TLS separé vers backends]
Le LB déchiffre pour répartir, mais le client a consenti implicitement (il parle au LB)
Coexistence dans une architecture réelle
Les deux coexistent souvent dans le même réseau, chacun à sa place :
┌────────────────────────────────────────────────────────────────┐
│ Réseau d'entreprise │
│ │
│ Serveurs internes ──► Forward Proxy ──► Internet │
│ (mises à jour apt, pull Docker, appels API externes) │
│ │
│ Internet ──► Load Balancer ──► Backends (API, frontend) │
│ (clients qui utilisent l'application) │
└────────────────────────────────────────────────────────────────┘
Exemple concret : un serveur backend sans accès Internet direct
# Le backend doit appeler une API externe (ex: Stripe)
# → passe par le forward proxy (trafic sortant)
# Les clients appellent le backend
# → passent par le load balancer (trafic entrant)
# Configuration côté backend
environment:
- http_proxy=http://squid.interne:3128 # sortant via proxy
# Le LB route les appels entrants automatiquement (transparent)Quand choisir quoi
| Besoin | Solution |
|---|---|
| Répartir la charge entre N backends | Load Balancer |
| Détecter et exclure les backends tombés | Load Balancer |
| Exposer un service avec TLS offloading | Load Balancer / Reverse Proxy |
| Contrôler ce que les employés font sur Internet | Forward Proxy |
| Mettre en cache les ressources externes | Forward Proxy |
| Journaliser les accès Internet pour conformité | Forward Proxy |
| Donner un accès Internet contrôlé à des serveurs sans IP publique | Forward Proxy |
| Inspecter le trafic HTTPS sortant | Forward Proxy (SSL inspection) |
En relation avec
- Proxy — Vue d’ensemble — hub : forward proxy, reverse proxy, comparatifs
- Forward Proxy — détail du mécanisme de proxy sortant
- Load Balancer — détail du répartiteur de charge
- Reverse Proxy — le pendant du LB : entrée unique devant les backends
- NAT — autre mécanisme qui masque les IPs (L3, sans inspection applicative)
- Forward Proxy vs NAT — comparaison proxy vs NAT couche par couche