Proxy inverse nginx : tutoriel complet de configuration

Un proxy inverse nginx est un serveur nginx qui accepte les requêtes entrantes au nom d’une ou plusieurs applications backend, puis transmet chaque requête à l’application backend appropriée et renvoie la réponse au client. Ce tutoriel propose une configuration de proxy inverse nginx complète, prête à l’emploi : un bloc server complet avec proxy_pass et en-têtes de transmission, équilibrage de charge upstream, terminaison SSL, prise en charge des WebSockets, réglage du buffering et des délais d’attente, gzip, routage avec location et corrections des erreurs 502 et 504 les plus fréquentes.

À la fin, vous disposerez d’une configuration de proxy inverse nginx exécutable, d’un modèle mental de la façon dont les pièces s’assemblent et d’une vision claire des situations dans lesquelles un proxy inverse nginx n’est plus l’outil adapté et dans lesquelles un proxy forward ou résidentiel prend le relais.

DataImpulse est un fournisseur de proxy éthique proposant plus de 90 millions d’adresses IP résidentielles, mobiles et de centre de données dans 195 pays. Il utilise un modèle de paiement à l’usage à partir de 1 dollar par Go avec du trafic sans expiration, et il est utilisé pour le web scraping, la vérification publicitaire, la surveillance des prix, l’étude de marché et la gestion multicompte.

nginx est-il un proxy inverse, et comment fonctionne-t-il ?

Oui, nginx est l’un des proxies inverses les plus utilisés, et le proxy inverse est une fonctionnalité native plutôt qu’un module complémentaire. Un proxy inverse se place devant vos serveurs backend, accepte les connexions clientes sur un nom d’hôte public et achemine chaque requête vers une application interne que le client ne voit jamais directement.

Pour clarifier les différents éléments, ce guide utilise un modèle simple. Nous l’appellerons le modèle de proxy inverse nginx à 5 couches, et chaque configuration fonctionnelle ci-dessous reprend simplement ces couches dans cet ordre :

• listen La directive listen et server_name déterminent quelles requêtes sont traitées par ce bloc (port 80, port 443, quel nom d’hôte).
• Routage avec location. Les blocs location associent les chemins entrants pour que /api/, /static/ et / soient acheminés vers des destinations différentes.
• Upstream. Le bloc upstream définit le pool de serveurs backend et la méthode d’équilibrage de charge.
• En-têtes. Les lignes proxy_set_header préservent le Host d’origine et l’IP du client pour que le backend reçoive la requête d’origine, et non nginx.
• TLS. ssl_certificate sur listen 443 termine le HTTPS au niveau de nginx pour que les backends puissent communiquer en HTTP en interne.

Si vous hésitez encore entre les deux directions de proxy, notre explication sur le proxy inverse contre le proxy forward explique le concept en détail. Cet article ne traite que du cas inverse. Pour la configuration sortante, côté client, consultez le guide complémentaire sur le proxy forward nginx.

De quoi avez-vous besoin avant de commencer ?

Vous avez besoin d’un serveur Linux sur lequel nginx est installé, d’au moins une application backend qui écoute sur un port local et, pour le HTTPS, d’un certificat TLS. Le proxy inverse n’utilise que la version standard de nginx, donc aucun module personnalisé ni recompilation n’est requis.

Confirmez que nginx est présent et que votre configuration est valide avant de modifier quoi que ce soit :

nginx -v
sudo nginx -t

Le test nginx -t analyse toute la configuration et signale les erreurs de syntaxe avec un fichier et un numéro de ligne. Exécutez-le après chaque modification dans ce tutoriel, car nginx refusera de recharger une configuration cassée et laissera l’ancienne en fonctionnement. Placez vos blocs server de proxy inverse dans /etc/nginx/conf.d/ ou /etc/nginx/sites-available/ selon votre distribution, et rechargez avec sudo nginx -s reload une fois le test réussi. Préparez également l’adresse du backend, par exemple une application Node ou Python sur 127.0.0.1:3000, car c’est la cible de proxy_pass.

Comment configurer un proxy inverse nginx étape par étape ?

Commencez par un seul bloc server qui écoute sur le port 80, transmet chaque requête à un backend avec proxy_pass et définit les en-têtes de transmission. Ajoutez ensuite l’équilibrage de charge, TLS, les WebSockets, le buffering et gzip. Ce premier bloc est la configuration minimale fonctionnelle d’un proxy inverse nginx :

server {
    listen 80;
    server_name app.example.com;

    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;
    }
}

Ces quatre lignes proxy_set_header ne sont pas facultatives. Sans elles, le backend voit nginx comme le client, enregistre la mauvaise IP dans ses journaux et peut construire des URL de redirection cassées. Host préserve le nom d’hôte demandé, X-Real-IP et X-Forwarded-For transmettent l’adresse réelle du client, et X-Forwarded-Proto indique à l’application si la requête d’origine était en HTTP ou HTTPS.

Ajoutez l’équilibrage de charge upstream. Pour répartir le trafic entre plusieurs instances backend, définissez un bloc upstream et faites pointer proxy_pass vers son nom. La méthode least_conn envoie chaque requête à l’instance ayant le moins de connexions actives :

upstream app_backend {
    least_conn;
    server 10.0.0.11:3000;
    server 10.0.0.12:3000;
    server 10.0.0.13:3000 backup;
}

server {
    listen 80;
    server_name app.example.com;

    location / {
        proxy_pass http://app_backend;
        proxy_set_header Host              $host;
        proxy_set_header X-Forwarded-For   $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

Le serveur backup ne reçoit du trafic que lorsque les serveurs principaux sont hors service. Remplacez least_conn par ip_hash si vous devez fixer le même client au même backend pour des sessions persistantes.

Terminez TLS sur le port 443. Les proxies inverses de production doivent prendre en charge HTTPS et rediriger le HTTP simple. nginx gère TLS pour que vos backends puissent rester en HTTP simple en interne :

server {
    listen 443 ssl;
    server_name app.example.com;

    ssl_certificate     /etc/letsencrypt/live/app.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/app.example.com/privkey.pem;
    ssl_protocols       TLSv1.2 TLSv1.3;

    location / {
        proxy_pass http://app_backend;
        proxy_set_header Host              $host;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

server {
    listen 80;
    server_name app.example.com;
    return 301 https://$host$request_uri;
}

Prenez en charge les WebSockets. Les connexions WebSocket commencent en HTTP puis basculent vers WebSocket, donc nginx doit transmettre les en-têtes Upgrade et Connection et utiliser HTTP/1.1. Attribuez une location dédiée aux chemins en temps réel :

location /ws/ {
    proxy_pass http://app_backend;
    proxy_http_version 1.1;
    proxy_set_header Upgrade    $http_upgrade;
    proxy_set_header Connection "upgrade";
    proxy_set_header Host       $host;
    proxy_read_timeout 3600s;
}

La valeur élevée de proxy_read_timeout empêche les connexions inactives d’être fermés en milieu de session, une cause fréquente de connexions temps réel interrompues.

Réglez le buffering et les délais d’attente. Les valeurs par défaut sont conservatrices ; les backends lents bénéficient de valeurs explicites pour que nginx ne ferme pas une connexion avant que l’application réponde :

location / {
    proxy_pass http://app_backend;
    proxy_connect_timeout 5s;
    proxy_send_timeout    60s;
    proxy_read_timeout    60s;
    proxy_buffering       on;
    proxy_buffers         16 16k;
    proxy_buffer_size     32k;
}

Activez gzip. Compresser les réponses transmises réduit la bande passante pour les ressources textuelles. Placez ceci dans le bloc http pour qu’il s’applique à tout le site :

gzip on;
gzip_types text/plain text/css application/json application/javascript;
gzip_min_length 1024;
gzip_comp_level 5;

Configurez le routage par chemin. Un seul proxy inverse peut servir plusieurs services en associant différents préfixes location à différents upstreams, en servant les fichiers statiques directement depuis le disque sans solliciter de backend :

server {
    listen 80;
    server_name example.com;

    location /api/ {
        proxy_pass http://api_backend;
        proxy_set_header Host $host;
    }

    location /static/ {
        root /var/www/assets;
    }

    location / {
        proxy_pass http://web_backend;
        proxy_set_header Host $host;
    }
}

Comment vérifier que le proxy inverse nginx fonctionne ?

Rechargez nginx, puis envoyez une requête au nom d’hôte public et confirmez que la réponse provient de votre backend et non d’une page nginx par défaut. Testez d’abord la configuration pour qu’une faute de frappe ne rende pas le site indisponible :

sudo nginx -t && sudo nginx -s reload
curl -I http://app.example.com

Un 200 ou une redirection attendue dans les en-têtes de la réponse signifie que le routage fonctionne. Pour prouver que le backend reçoit les en-têtes de transmission, vérifiez son journal d’accès ou un endpoint d’écho et confirmez qu’il voit la véritable IP du client depuis X-Forwarded-For, et non 127.0.0.1. Vous pouvez aussi contourner le DNS et cibler directement le proxy en définissant manuellement le nom d’hôte :

curl -H "Host: app.example.com" http://127.0.0.1

Pour le HTTPS, exécutez curl -I https://app.example.com et vérifiez que le certificat est accepté et qu’il n’y a pas de retour vers HTTP. Si le backend génère des liens ou des redirections avec le mauvais schéma, c’est presque toujours un en-tête X-Forwarded-Proto manquant plutôt qu’un problème de TLS.

Comment dépanner les erreurs 502 et 504 ?

Une erreur 502 Bad Gateway signifie que nginx a atteint l’upstream mais a reçu une réponse invalide ou que la connexion a été refusée, tandis qu’une 504 Gateway Timeout signifie que l’upstream a accepté la connexion mais n’a pas répondu à temps. Ces deux erreurs proviennent de l’upstream, et non des bugs de nginx, et le journal des erreurs indique la cause exacte. Observez-le en direct pendant que vous reproduisez la requête :

sudo tail -f /var/log/nginx/error.log
# [error] connect() failed (111: Connection refused) while connecting to upstream

Passez en revue les causes habituelles dans l’ordre :

• 502, connexion refusée. Le backend n’est pas en cours d’exécution ou écoute sur une adresse ou un port différent de ce que proxy_pass vise. Confirmez avec curl http://127.0.0.1:3000 sur le serveur lui-même.
• 502, SELinux ou pare-feu. Sur les systèmes de la famille RHEL, SELinux empêche nginx d’ouvrir des connexions sortantes jusqu’à ce que vous exécutiez setsebool -P httpd_can_network_connect 1.
• 504, backend lent. L’application met plus de temps que proxy_read_timeout à répondre. Augmentez le délai d’attente pour cette location, ou corrigez la requête lente, plutôt que de la masquer globalement.
• 502, en-têtes volumineux. Un backend envoyant de gros en-têtes de réponse peut déborder les buffers du proxy. Augmentez proxy_buffer_size et proxy_buffers.
• Mauvais upstream choisi. Si un serveur d’un pool upstream est hors service, nginx le marque comme défaillant et réessaie avec le suivant, donc des 502 intermittents pointent souvent vers un seul backend défaillant.

Quel proxy inverse convient, et quand avez-vous besoin d’un proxy différent ?

Utilisez un proxy inverse nginx lorsque vous terminez les connexions TLS, équilibrez la charge ou routez des chemins devant vos propres serveurs ; tournez-vous vers un proxy forward ou résidentiel lorsque la tâche consiste à envoyer des requêtes sortantes depuis de nombreuses IP. nginx excelle pour le trafic entrant et n’est pas conçu pour le trafic sortant. Voici la matrice de décision :

• Utilisez un proxy inverse nginx lorsque vous hébergez le backend, vous voulez un unique endpoint HTTPS public devant plusieurs services internes, vous avez besoin d’un équilibrage de charge entre instances, ou vous souhaitez activer le cache et gzip en périphérie.
• Évitez nginx comme proxy lorsque l’objectif est des requêtes sortantes qui doivent sembler provenir de nombreuses IP ou pays différents, car un proxy inverse sort depuis l’IP de votre unique serveur et ne peut pas faire tourner les IP.

Parmi les proxies inverses en particulier, nginx, Caddy et HAProxy offrent des compromis différents :

Pour l’automatisation sortante intensive, notre guide des meilleures pratiques de web scraping couvre la rotation et le contrôle du débit, et les proxies de centre de données ou les proxies mobiles conviennent aux tâches où le coût ou les IP d’opérateur sont plus importants que l’authenticité résidentielle.

Quelles sont les limites et les risques d’un proxy inverse nginx ?

Un proxy inverse nginx est puissant pour le trafic entrant mais présente de vraies limites : il ne peut pas faire tourner les IP sortantes, des en-têtes mal configurés peuvent divulguer ou masquer l’identité du client, et il ajoute un composant opérationnel à administrer et à surveiller. Connaître ces éléments permet de définir des attentes réalistes.

• IP de sortie unique. Chaque requête sortante du proxy passe par l’IP propre au serveur, donc un proxy inverse ne peut pas aider pour les tâches qui nécessitent de nombreuses adresses sources.
• Les erreurs d’en-tête sont silencieuses. Oublier X-Forwarded-For empêche votre application et son mécanisme de limitation de débit de connaître l’IP réelle du client ; oublier X-Forwarded-Proto empêche les redirections HTTPS de fonctionner correctement. nginx ne vous avertira pas.
• Entretien de TLS et des certificats. Les certificats expirent, donc le renouvellement et les rechargements vous incombent, généralement via certbot et une tâche cron ou un timer systemd.
• Un nouveau point de défaillance. Le proxy est désormais dans le chemin critique ; s’il tombe en panne, tous les backends derrière lui deviennent injoignables, c’est pourquoi les vérifications de bon fonctionnement et la surveillance comptent.
• Ce n’est pas un outil d’anonymat sortant. Un proxy inverse n’est pas conçu pour masquer l’origine des requêtes. C’est le travail d’un proxy forward.

nginx n’est pas un produit DataImpulse, et DataImpulse ne vend ni API de scraping gérée ni proxy web gratuit. Exécutez nginx vous-même là où il convient ; lorsque vous avez besoin de requêtes sortantes à grande échelle, DataImpulse obtient ses IP de manière éthique auprès de proxies éthiques qui y consentent et sont rémunérés. Dernière mise à jour : 2026-07-22.

Foire aux questions

Guides connexes

• Proxy forward NGINX
• Proxy inverse Cloudflare
• Proxy inverse Docker

Besoin d’IP sortantes que nginx ne peut pas faire tourner ?

Un proxy inverse gère le trafic entrant, mais lorsque votre tâche nécessite des requêtes sortantes depuis de nombreuses vraies IP, DataImpulse donne accès à plus de 90 millions d’IP résidentielles, mobiles et de centre de données rotatives dans 195 pays, avec une facturation à l’usage à partir d’un dollar par Go avec du trafic sans expiration. Créez un compte pour obtenir des identifiants de passerelle et acheminer les requêtes de votre client vers le pool.