Reverse proxy contre forward proxy
Un forward proxy travaille pour le client. Le navigateur est configuré pour l'utiliser, et il récupère l'internet pour le compte du navigateur — filtrage de sortie en entreprise, et la plupart de ce que les gens entendent en cherchant « proxy ».
Un reverse proxy travaille pour le serveur. Les clients n'ont aucune idée qu'il existe ; ils résolvent votre nom d'hôte, il répond, et il décide quoi faire de la requête. Votre application peut être sur une autre machine, dans un conteneur, ou répartie sur dix d'entre eux.
La distinction compte parce que les résultats de recherche la brouillent. Si une page sur les « serveurs proxy » parle de débloquer des sites web, elle ne parle pas de la chose qui se trouve devant votre application.
Ce que vous y gagnez réellement
Terminaison TLS. Les certificats vivent à un seul endroit au lieu d'être sur chaque serveur d'application. Le renouvellement devient une seule tâche.
Routage. Un nom d'hôte, plusieurs backends : /api vers le service Node, / vers WordPress, /static vers le stockage d'objets. Le client voit un seul site.
Mise en cache. Le proxy répond lui-même aux requêtes répétées. C'est le plus gros gain de performance disponible pour la plupart des sites, et celui qu'on laisse le plus souvent désactivé.
Compression. Brotli ou gzip appliqué une fois en bordure de votre stack plutôt que dans chaque application.
Rate limiting et filtrage. Un endroit pour appliquer des limites et bloquer le trafic avant qu'il n'atteigne du code qui coûte de l'argent à exécuter.
Dissimulation de l'origine. Si votre serveur d'application n'est joignable que depuis le proxy, les attaques doivent passer par la porte que vous contrôlez.
Un endroit pour changer le comportement. Redirections, réécritures d'en-têtes et pages de maintenance qui ne nécessitent pas de déploiement applicatif.
Une configuration nginx fonctionnelle
Le minimum réellement correct — les en-têtes ci-dessous ne sont pas une décoration optionnelle, ce sont eux qui font que votre application voit le client plutôt que le proxy :
``` server { listen 443 ssl; server_name example.com;
ssl_certificate /etc/ssl/example.com/fullchain.pem; ssl_certificate_key /etc/ssl/example.com/privkey.pem;
location / { proxy_pass http://127.0.0.1:3000;
proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme;
proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; } } ```
Host — sans lui, le backend voit 127.0.0.1 et toute URL absolue qu'il construit est fausse.
X-Forwarded-For et X-Real-IP — sans eux, chaque requête dans le journal de votre application provient du proxy, et toute logique par IP que vous avez s'applique silencieusement au proxy plutôt qu'au visiteur.
X-Forwarded-Proto — sans lui, une application derrière une terminaison TLS croit être en HTTP simple et génère des liens http://, ce qui produit la boucle de redirection qui coûte à tout le monde un après-midi au moins une fois.
La paire Upgrade — sans elle, les WebSockets ne fonctionnent pas, et l'échec ressemble à un bug applicatif plutôt qu'à un bug de proxy.
La mise en cache au niveau du proxy, en bref
nginx peut mettre en cache les réponses upstream avec proxy_cache. La mécanique est assez simple : déclarer un chemin de cache, l'activer dans la location, et décider ce qui est stocké et pour combien de temps.
``` proxy_cache_path /var/cache/nginx keys_zone=site:50m max_size=5g inactive=24h;
location / { proxy_cache site; proxy_cache_valid 200 10m; proxy_cache_key "$scheme$request_method$host$request_uri"; add_header X-Cache-Status $upstream_cache_status; proxy_pass http://127.0.0.1:3000; } ```
Deux choses décident si cela aide ou fait mal.
La clé de cache. Par défaut, elle inclut l'URI complète, donc ?utm_source=twitter crée une entrée séparée de l'URL propre. Une campagne peut fragmenter votre cache en milliers de copies d'une même page et faire tomber le taux de hit à rien. Retirez les paramètres qui ne changent pas la réponse.
La purge. nginx open source n'a aucun mécanisme de purge ; vous attendez le TTL ou vous supprimez des fichiers du répertoire de cache à la main, sur chaque machine. C'est généralement le point où « nous gérons notre propre proxy » commence à faire mal, car publier une correction et attendre dix minutes qu'elle apparaisse n'est un workflow que personne n'apprécie.
Ce que gérer le vôtre coûte réellement
Un seul nginx devant une seule application est bon marché et tout à fait raisonnable. Le coût arrive plus tard, par morceaux.
C'est une machine unique. Un reverse proxy qui est le seul point d'entrée est aussi la seule chose qui doit rester en ligne. Le rendre redondant signifie une seconde machine, une adresse flottante ou un basculement DNS, et une config identique sur les deux.
Les certificats. Le renouvellement automatisé est un problème résolu jusqu'à ce que le hook de renouvellement du second nœud échoue silencieusement et que vous l'appreniez par un avertissement de navigateur.
L'invalidation du cache entre les nœuds. Avec deux proxys, vous avez deux caches, et purger signifie le faire sur les deux, de façon fiable, depuis votre pipeline de déploiement.
C'est en un seul endroit. Vos visiteurs, eux, ne le sont pas. Un proxy dans un datacentre ne peut pas être proche d'utilisateurs dans un autre pays ; c'est un problème de physique, pas de configuration.
Le réglage est permanent. Tailles de buffer, timeouts, keepalive vers les upstreams, connexions worker — chacun de ces réglages va bien à votre trafic actuel et devient faux à dix fois ce trafic.
Quand confier la tâche à quelqu'un d'autre
Un CDN est un reverse proxy que quelqu'un d'autre exploite dans de nombreux emplacements. Les fonctions sont les mêmes — terminaison TLS, mise en cache, compression, filtrage, routage — et les différences sont les parties qui étaient difficiles : la géographie, la redondance, et la purge instantanée sur chaque nœud.
La ligne raisonnable est la suivante. Gardez votre propre proxy tant qu'il fait du travail local : routage entre services à l'intérieur d'une machine ou d'un cluster, exécution de règles qui dépendent d'un état interne. Confiez le côté public dès que vous vous retrouvez à résoudre des problèmes de distribution — un second nœud pour la redondance, une purge de cache entre machines, des visiteurs dans un autre pays qui attendent un aller-retour jusqu'au vôtre.
La plupart des équipes finissent avec les deux, et c'est l'arrangement raisonnable : un CDN faisant face à l'internet, et un petit nginx à l'intérieur faisant le routage pour lequel il est doué. Ce que vous ne voulez pas, c'est passer un trimestre à reconstruire, mal, les parties qu'un CDN vous donne dès le premier jour.
FAQ reverse proxy
Un reverse proxy est-il la même chose qu'un load balancer ?
Ils se recoupent. Un load balancer distribue les requêtes entre plusieurs backends ; un reverse proxy termine aussi le TLS, met en cache, réécrit et filtre. nginx fait les deux, ce qui explique pourquoi les termes sont utilisés indifféremment. Si la seule tâche est de répartir le trafic entre des serveurs identiques, « load balancer » est le mot le plus précis.
Un reverse proxy ralentit-il mon site ?
Il ajoute un saut, de l'ordre de quelques millisecondes quand le proxy est proche de l'origine, et il en retire bien plus que ça quand la mise en cache est active — une réponse en cache ne voyage jamais jusqu'à votre application. Le cas où cela fait mal, c'est un proxy dans une région différente à la fois de vos utilisateurs et de votre origine.
Pourquoi mon application voit-elle l'IP du proxy au lieu de celle du visiteur ?
Parce que les en-têtes forwarded sont absents, ou parce que l'application n'est pas configurée pour leur faire confiance. Les deux moitiés sont nécessaires : le proxy envoie X-Forwarded-For, et il faut dire au framework quelles adresses de proxy il peut croire. Faire confiance à l'en-tête venant de n'importe où permet à un client de usurper sa propre IP.
Puis-je mettre en cache des pages où l'utilisateur est connecté ?
Pas par défaut, et en général vous ne devriez pas le vouloir — c'est ainsi qu'un utilisateur voit le tableau de bord d'un autre utilisateur. Le schéma normal consiste à contourner le cache quand un cookie de session est présent, et à mettre en cache agressivement pour les visiteurs anonymes, qui représentent l'essentiel du trafic sur la plupart des sites.
Comment purger un cache de proxy nginx ?
nginx open source n'a aucune directive de purge. Les options sont de supprimer les fichiers concernés du répertoire de cache sur chaque nœud, d'utiliser le module de purge tiers, ou d'attendre le TTL. La purge à la demande sur plusieurs machines est l'une des choses concrètes que vous obtenez en déplaçant la couche de cache vers un CDN.