Quand une application répond depuis un serveur situé derrière un pare-feu, vous pouvez vouloir centraliser les accès, répartir le trafic ou appliquer des règles communes avant qu’une requête n’atteigne le service. Le reverse proxy remplit ce rôle d’intermédiaire côté serveur : pour l’internaute, il ressemble au site qu’il consulte, tandis qu’il choisit en coulisse où envoyer la demande.
Pour savoir s’il vous est utile, il faut distinguer ses fonctions, les options de déploiement et les vérifications à prévoir. Le choix dépend notamment du nombre de services, de leur emplacement, des besoins de disponibilité et de la personne qui exploitera la configuration.
Que se passe-t-il entre le navigateur et le serveur ?
Le navigateur envoie une requête HTTP ou HTTPS à une adresse publique. Le reverse proxy la reçoit, examine des éléments configurés comme le nom de domaine ou le chemin demandé, puis la transmet à un serveur d’origine, souvent appelé backend. Ce serveur traite la requête et renvoie une réponse au proxy, qui la restitue au navigateur. L’utilisateur voit une seule adresse publique, même si plusieurs services fonctionnent en coulisse.
La documentation d’Apache décrit ce rôle de passerelle : le serveur intermédiaire peut recevoir les requêtes et les transmettre à un ou plusieurs serveurs backend. Elle distingue cette fonction du proxy direct, où le client demande explicitement au proxy d’accéder à un serveur externe. Vous retrouverez ces usages et d’autres notions dans la rubrique Technologie.
Une configuration très simple pourrait envoyer les requêtes de app.exemple.fr vers un service interne sur le port 8000, tandis que fichiers.exemple.fr pointe vers un autre service. Le proxy ne crée pas lui-même l’application : il organise l’accès et peut traiter certaines fonctions communes avant de transmettre le trafic.
Quelles fonctions pouvez-vous lui confier ?
La fonction de base est le routage : diriger les requêtes vers le bon backend. Selon le logiciel et sa configuration, un reverse proxy peut également répartir le trafic entre plusieurs serveurs, mettre en cache certaines réponses, gérer une partie du chiffrement HTTPS ou centraliser des règles d’accès. Ce sont des capacités possibles, pas des résultats automatiques : elles doivent être configurées et adaptées à l’application.
Le chiffrement mérite une attention particulière. Si le proxy reçoit une connexion HTTPS et communique ensuite avec un backend en HTTP, le trajet entre les deux n’est pas chiffré. Cela peut convenir dans un réseau isolé et maîtrisé, mais pas sans évaluer les risques du réseau interne. Une autre possibilité consiste à chiffrer aussi la connexion vers le backend. Dans les deux cas, déterminez où les certificats sont installés, qui les renouvelle et comment les erreurs d’expiration seront repérées.
Les en-têtes transmis au backend sont tout aussi importants. Une application peut s’appuyer sur l’adresse IP du visiteur, le nom d’hôte demandé ou le protocole d’origine pour produire des journaux, liens et redirections. Le proxy doit alors transmettre les informations nécessaires, et le backend ne doit faire confiance qu’aux en-têtes provenant du proxy attendu. Sinon, les journaux peuvent attribuer une mauvaise adresse au visiteur ou l’application peut générer des redirections incohérentes.
Un cache placé dans le proxy peut éviter de recalculer certaines réponses, mais ne doit pas conserver par erreur des pages personnalisées, des informations de session ou des données sensibles. Commencez sans cache si vous ne savez pas quelles réponses sont publiques et réutilisables. Pour chaque règle, identifiez les URL concernées, les en-têtes ou cookies qui rendent une réponse spécifique, et le comportement attendu lors d’une mise à jour du contenu.
Comment choisir entre une solution locale et un service externalisé ?
Le bon choix dépend de l’exploitation, pas seulement de la liste de fonctions. Un reverse proxy installé sur une machine que vous gérez vous donne la maîtrise des règles et du chemin réseau, mais vous rend responsable de sa disponibilité, de ses mises à jour, des certificats, des journaux et des tests. Un service externalisé peut prendre en charge une partie de l’infrastructure en amont ; il ajoute en contrepartie une dépendance à un fournisseur et nécessite de vérifier les flux, les réglages et le traitement des données.
Les documentations donnent des exemples de différences entre logiciels. Apache mod_proxy s’appuie sur des modules selon les protocoles et options employés, et sa documentation décrit le routage avec ProxyPass et l’ajustement de certaines réponses avec ProxyPassReverse. NGINX utilise notamment proxy_pass pour indiquer le serveur cible ; sa documentation précise que le chemin transmis dépend de la présence ou non d’une URI dans cette directive. Le choix doit donc tenir compte de votre environnement existant, des compétences d’administration disponibles, des protocoles nécessaires et de la façon dont vous testerez les changements.
Un service cloud peut aussi jouer le rôle de reverse proxy. Cloudflare décrit le cheminement des requêtes HTTP et HTTPS lorsque l’enregistrement DNS est configuré en mode proxifié : le trafic passe par son réseau avant de rejoindre le serveur d’origine. Ce modèle peut réunir plusieurs fonctions, mais il faut vérifier quels noms d’hôte et types de trafic passent effectivement par le service, et comment l’accès direct au serveur d’origine est contrôlé.
Si vos services sont hébergés sur un serveur NAS, vérifiez d’abord les capacités et les limites de l’appareil, les mises à jour disponibles et les services que vous comptez rendre accessibles. Un proxy placé sur le NAS peut être simple à exploiter pour un petit nombre d’applications, mais il concentre aussi les dépendances sur cette machine. Un proxy distinct ajoute un équipement ou un service à surveiller. Dans tous les cas, conservez des sauvegardes séparées de la configuration et des données importantes.
Comment préparer une mise en place sans oublier l’essentiel ?
Avant de modifier la configuration, établissez une carte courte des flux : nom public, protocole reçu, serveur et port de destination, chemins concernés, authentification attendue et présence éventuelle de WebSocket. Notez aussi quels services doivent rester privés. Cela rend les règles compréhensibles et facilite le retour arrière si un changement bloque un accès.
Procédez ensuite par étapes :
- Choisissez un seul service de test et confirmez qu’il répond directement depuis le réseau où sera installé le proxy.
- Créez une règle ciblée qui associe un nom ou un chemin à ce service, sans ouvrir un accès général à des destinations arbitraires.
- Configurez le HTTPS, les en-têtes indispensables et les délais d’attente selon le comportement de l’application.
- Testez les pages, les connexions persistantes, les téléversements et les redirections utilisés par le service.
- Activez la journalisation utile, appliquez la configuration, puis gardez une procédure de retour à la version précédente.
Les exemples doivent être adaptés et non copiés sans vérification. Apache avertit que l’activation d’un proxy direct ouvert est dangereuse ; un reverse proxy correctement limité à des destinations définies n’a pas le même usage. NGINX indique que proxy_pass fixe le protocole et l’adresse du serveur transmis, et explique comment la partie URI d’une requête peut être remplacée. Vérifiez les barres obliques finales et le chemin obtenu côté backend : une divergence entre le préfixe public et le chemin attendu peut produire des erreurs difficiles à distinguer d’une panne applicative.
Pour les connexions WebSocket, qui permettent notamment des échanges persistants entre navigateur et application, vérifiez le support et les réglages propres au logiciel choisi. La documentation NGINX précise que le proxy WebSocket nécessite une configuration particulière. La documentation Apache indique que mod_proxy_http peut traiter les mises à niveau de protocole depuis Apache HTTP Server 2.4.47 ; les versions antérieures peuvent nécessiter une autre configuration. Ces précisions concernent les versions documentées : confirmez les directives disponibles pour la version réellement installée.
Comment vérifier que le proxy fait bien son travail ?
Testez chaque nom de domaine et chaque chemin depuis l’extérieur du réseau d’administration, puis comparez le résultat à un accès interne. Vérifiez les codes HTTP, le contenu reçu, les redirections, les cookies, l’adresse IP journalisée par l’application et le certificat présenté au navigateur. Un test réussi sur la page d’accueil ne prouve pas que les formulaires, les fichiers volumineux ou les connexions WebSocket fonctionnent également.
Observez séparément les journaux du proxy et du backend. Si le proxy renvoie une erreur de passerelle, vérifiez d’abord que le backend fonctionne, que le nom ou l’adresse cible est résolu et que le port est joignable depuis la machine proxy. Si l’application renvoie des URL internes ou redirige vers HTTP, contrôlez les en-têtes de protocole et d’hôte transmis, ainsi que les paramètres de confiance de l’application. Gardez à l’esprit qu’un délai d’attente du proxy ne prouve pas à lui seul que le backend est arrêté.
NGINX documente un délai de lecture de réponse par défaut de 60 secondes pour proxy_read_timeout. Il s’agit du délai entre deux lectures successives, et non d’une limite générale sur la durée totale d’une réponse. Une application qui transmet des données lentement ou laisse une connexion inactive peut donc se comporter autrement qu’une requête courte. Ajustez les délais à partir du comportement attendu et des mesures observées plutôt que de les augmenter indistinctement.
Enfin, testez les pannes prévues : arrêt d’un backend, certificat expiré en environnement de test, mauvais chemin et redémarrage du proxy. Vérifiez la procédure de retour arrière et la restauration de la configuration. Un reverse proxy est utile lorsqu’il simplifie réellement l’accès et l’exploitation ; s’il devient un point unique dont personne ne suit les journaux, les mises à jour et la disponibilité, il ajoute une dépendance plutôt qu’une résilience.
Questions fréquentes
Un reverse proxy est-il la même chose qu’un proxy classique ?
Non. Un proxy direct, ou forward proxy, est généralement utilisé par des clients pour accéder à des serveurs externes ; le client doit savoir qu’il passe par lui. Un reverse proxy se place devant les serveurs d’une organisation : le navigateur envoie une requête normale à l’adresse du site, et le proxy la transmet vers le serveur configuré. Le sens du service rendu et la partie qui le configure diffèrent.
Un reverse proxy remplace-t-il un pare-feu ?
Non. Il peut limiter les services accessibles et transmettre les requêtes selon des règles, mais il ne remplace pas une politique de filtrage réseau ni la sécurisation des serveurs et applications. Il faut contrôler les accès, les ports exposés, les mises à jour et les informations transmises dans les en-têtes. Le reverse proxy constitue une couche d’architecture, pas une garantie générale de sécurité.
Peut-on utiliser un reverse proxy chez soi avec un NAS ?
Oui, si le NAS héberge ou dessert des services auxquels vous souhaitez accéder par des noms d’hôte ou des chemins web. Le proxy peut centraliser les requêtes, mais il ne remplace ni les sauvegardes ni le contrôle des accès. Avant d’exposer un service à Internet, vérifiez les mises à jour du NAS et de chaque application, limitez les services publiés et testez l’accès depuis un réseau extérieur.
