Un proxy relaie des échanges, mais son rôle dépend de la partie pour laquelle il intervient. Un proxy de sortie agit pour les utilisateurs ; un reverse proxy reçoit les requêtes destinées à un service. Cette distinction permet de choisir une architecture et d’éviter de confondre relais, chiffrement et protection complète.
| Question | Proxy de sortie | Reverse proxy |
| Pour qui intervient-il ? | Les clients d’un réseau. | Le service et ses serveurs. |
| Exemple | Accès web contrôlé dans une entreprise. | Entrée d’un site répartie sur plusieurs serveurs. |
| Objectif possible | Appliquer des règles de sortie. | Router, filtrer ou mettre en cache les réponses. |
Un exemple de réseau d’entreprise montre le rôle du proxy de sortie
Imaginez un salarié qui consulte un site depuis le réseau de son entreprise. Un forward proxy peut recevoir sa demande, appliquer les règles du réseau, puis relayer l’échange vers le site. L’entreprise organise ainsi les accès de plusieurs postes à travers un point contrôlé.
Cela ne signifie pas automatiquement que toutes les applications du poste passent par ce relais. Le périmètre dépend du protocole, du paramétrage du client et de l’architecture. Il faut vérifier les usages réellement couverts plutôt que déduire une protection globale d’un réglage dans le navigateur.
Le site peut voir l’adresse du relais, mais l’utilisateur peut rester identifiable par un compte connecté, des cookies ou d’autres informations. Un proxy n’est donc pas une garantie d’anonymat. Il n’apporte pas non plus, par son seul nom, les mêmes propriétés qu’un VPN correctement configuré.
Un reverse proxy devient l’entrée du service pour ses visiteurs
Pour un site, le reverse proxy reçoit la requête du visiteur puis la transmet au serveur choisi. Il peut gérer la répartition du trafic, certaines fonctions de sécurité et le cache. Cloudflare explique ces usages et la différence avec le proxy côté client.
La terminaison TLS, lorsqu’elle est configurée au niveau du proxy, implique deux trajets à examiner : visiteur vers proxy et proxy vers origine. Le chiffrement du premier ne suffit pas à décrire le second. Les certificats, règles de connexion et possibilités d’accès direct à l’origine doivent être contrôlés séparément.
Le cache doit distinguer contenu public et réponses personnalisées
Une image publique peut souvent être partagée entre visiteurs. Une page de compte, un panier ou une réponse contenant des données personnelles demande une politique différente. Copier une configuration de cache sans comprendre sessions, cookies et autorisations peut exposer des informations ou afficher des données périmées.
La documentation NGINX décrit notamment les règles de contournement et de non-stockage du cache. Ces mécanismes doivent être choisis selon l’application, puis testés avec des utilisateurs connectés et déconnectés. Un cache performant n’est utile que si les réponses restent correctes.
- Tester une page publique avant et après modification.
- Tester un compte connecté et vérifier l’absence de partage entre utilisateurs.
- Vérifier le passage des en-têtes et la reconnaissance de l’adresse client.
- Observer les erreurs et les délais quand l’origine devient indisponible.
- Prévoir comment purger une réponse mise en cache.
Le choix d’un logiciel vient après ces besoins : routage, disponibilité, sécurité et exploitation. Un reverse proxy n’intègre pas nécessairement un WAF ou une protection DDoS complète. Définissez ce que chaque couche doit faire et comment vous vérifierez son fonctionnement.
Mise à jour du 30 septembre 2026 : guide revu, informations vérifiées et conseils pratiques précisés.
Je suis Romain Delcourt, rédacteur tech passionné par le numérique et l’intelligence artificielle. J’écris pour décoder les tendances, les outils et les changements qui façonnent nos usages au quotidien.
