Niveau 🟡 intermédiaire
Durée estimée : 25 min · Prérequis : Pare-feu
Un reverse proxy, c'est la rĂ©ceptionniste d'un immeuble de bureaux partagĂ©. Personne Ă
l'extérieur ne connaît directement le numéro de bureau de chaque entreprise — tout le monde
s'adresse à la réceptionniste, qui redirige vers le bon étage selon le nom demandé. Une seule
adresse visible de l'extérieur, autant de destinataires internes que nécessaire derrière.
Un reverse proxy est un serveur qui reçoit les requêtes destinées à plusieurs services
internes, et qui les redirige vers le bon service selon des critères comme le nom de domaine
demandé — tout en présentant une seule adresse (et souvent un seul port, 443 en HTTPS) vue de
l'extérieur ou du réseau local.
Reverse proxy, par opposition Ă un proxy classique : un proxy classique agit pour le
client — il cache l'identitĂ© du client vis-Ă -vis des serveurs qu'il contacte (« je navigue Ă
travers un proxy pour rester anonyme »). Un reverse proxy agit pour le serveur — il cache
l'organisation interne des services vis-à -vis des clients (« le client ne sait pas combien de
serveurs se trouvent réellement derrière cette seule adresse »). Le sens du mot « reverse »
vient précisément de cette inversion de qui est protégé.
Pourquoi c'est central dans un homelab, au-delà de la simple commodité :
HostComment un service rejoint le reverse proxy, en pratique : le service et le reverse proxy
partagent un réseau Docker commun, dédié à cet usage. Le reverse proxy peut alors joindre
chaque service par son nom de conteneur, résolu automatiquement par le DNS interne de
Docker — sans jamais passer par l'adresse IP de la machine hôte. Ajouter un nouveau service
revient à : connecter son conteneur à ce réseau partagé, puis déclarer dans le reverse proxy
« pour tel nom de domaine, rediriger vers tel nom de conteneur, sur tel port interne ».
⚠️ Le piège du hairpin NAT. Pointer la configuration du reverse proxy vers l'adresse IP
de la machine hĂ´te plutĂ´t que vers le nom du conteneur (ou127.0.0.1) peut provoquer un
Ă©chec de connexion : le trafic part du reverse proxy, ressort vers l'IP de la machine, doit
alors « faire demi-tour » (d'où hairpin, épingle à cheveux) pour revenir vers un conteneur
de cette même machine — un aller-retour que certaines configurations réseau gèrent mal.
Utiliser le nom du conteneur sur le réseau Docker partagé évite complètement ce détour.
🧪 Concrètement, sur notre exemple : Nginx Proxy Manager (NPM) est le reverse proxy
utilisé, et chaque service (supervision, monitoring, Portainer...) rejoint un réseau Docker
partagé dédié à cet usage. NPM les joint chacun par leur nom de conteneur —Uptime Kuma
devient une adresse interne du typehttp://uptime-kuma:3001, jamais l'adresse IP de la
machine hôte. Ajouter un service suit toujours la même méthode : connecter son conteneur à ce
réseau partagé, puis créer un « Proxy Host » dans NPM qui pointe vers ce nom de conteneur.
Le client ne voit jamais qu'une seule adresse (celle du reverse proxy) : c'est lui qui lit le nom
demandé et redirige, via le réseau Docker partagé, vers le bon conteneur en interne.
docker network ls
# Liste les réseaux Docker existants -- le réseau partagé du reverse
# proxy doit y apparaître (souvent créé une fois manuellement)
docker network connect <reseau-partage> <nom-conteneur>
# Connecte un conteneur existant au réseau partagé du reverse proxy,
# lui permettant d'être joint par son nom depuis ce réseau
docker exec <conteneur-reverse-proxy> ping -c1 <nom-conteneur>
# Depuis le conteneur du reverse proxy, vérifie que le nom du service
# cible se résout bien -- confirme que les deux sont sur le même réseau
Depuis une machine du réseau local, ouvre un navigateur vers le nom de domaine interne d'un
service passant par le reverse proxy. La page doit s'afficher normalement, sans que le
navigateur n'ait jamais eu besoin de connaître le port réel du service ni son adresse interne.
| SymptĂ´me | Cause probable | Solution |
|---|---|---|
| « Bad Gateway » dans le reverse proxy | Le conteneur cible n'est pas sur le même réseau Docker partagé | Vérifier avec docker network ls / docker inspect que les deux conteneurs partagent bien ce réseau |
| Connexion qui échoue en pointant vers l'IP de la machine hôte | Piège du hairpin NAT (voir encadré ci-dessus) | Pointer vers le nom du conteneur sur le réseau partagé, jamais vers l'IP de l'hôte |
| Un service ajouté n'apparaît pas joignable par son nom de domaine | Oubli de créer le « Proxy Host » côté reverse proxy après avoir connecté le conteneur | Les deux étapes sont indépendantes : connexion réseau et déclaration du routage doivent être faites toutes les deux |
Un proxy classique protège l'identité du client vis-à -vis des serveurs contactés. Un reverse
proxy protège l'organisation interne des serveurs vis-à -vis des clients qui s'y connectent.
Pour éviter le piège du hairpin NAT (aller-retour raté du trafic qui doit « faire demi-tour »
vers un conteneur de la mĂŞme machine), et parce que le nom du conteneur reste stable mĂŞme si son
IP interne change.
Connecter le conteneur du service au réseau Docker partagé, et déclarer le routage
(nom de domaine → nom de conteneur/port) côté configuration du reverse proxy.
Sur une machine avec Docker, crée un réseau dédié (docker network create test-proxy),
connecte-y deux conteneurs différents, puis vérifie depuis l'un qu'il peut joindre l'autre par
son nom (ping ou curl vers le nom du second conteneur).
reverse proxy ·
proxy ·
hairpin NAT ·
SNI
Cette formation est proposée par Deladev, studio web de Loïc D. — création de sites et d'applications, accompagnement et formation sur mesure.
Les projets réalisés · Prestations et tarifs · Le blog tech · Me contacter
Écrite par Loïc D. avec l'assistance de Claude (Anthropic) — un travail à deux.
© 2026 Deladev — publiée sous licence CC BY-NC-ND 4.0. Vous pouvez la lire, y renvoyer par un lien, la partager et la citer en créditant la source. La revendre, l'utiliser dans une prestation ou une formation payante, la republier même partiellement ailleurs, en diffuser une version modifiée ou l'exploiter pour entraîner un modèle d'IA nécessitent une autorisation écrite — pour un usage interne en entreprise, c'est souvent oui, il suffit de demander.