Nginx reverse proxy sur VPS : configuration complète avec SSL et sécurité

Vous avez déployé une application sur votre VPS Linux, par exemple une application Node.js sur le port 3000, une API Python sur le port 8000 ou un service Docker exposé sur un port local. Techniquement, l’application fonctionne. Mais la rendre accessible directement depuis Internet via http://votre-ip:3000 n’est ni sécurisé, ni pratique, ni professionnel.✨

Sans reverse proxy, chaque application expose son propre port, souvent sans certificat SSL, avec une configuration difficile à maintenir dès que plusieurs services cohabitent sur le même serveur. Nginx permet de résoudre ce problème en servant de point d’entrée unique.💥 Dans ce tutoriel, vous allez apprendre à configurer Nginx comme reverse proxy sur un VPS Linux afin d’exposer vos applications proprement, en HTTPS, avec une configuration claire et évolutive.😊

Objectif

👇L’objectif de cet article est de vous guider pas à pas dans la mise en place d’un reverse proxy Nginx sur un VPS Linux, principalement sous Debian ou Ubuntu. Vous verrez comment installer Nginx, créer un premier fichier de configuration, rediriger un nom de domaine vers une application locale, puis sécuriser l’ensemble avec un certificat SSL Let’s Encrypt via Certbot.🔒 Nous verrons également comment ajouter des headers de sécurité, héberger plusieurs applications sur le même VPS, gérer certains cas avancés comme Docker ou WebSocket, puis diagnostiquer les erreurs les plus fréquentes. À la fin de ce guide, vous disposerez d’une configuration Nginx opérationnelle, capable de servir une ou plusieurs applications derrière un seul serveur, avec HTTPS forcé et une base de sécurité solide.✨

Pourquoi un reverse proxy : ce que ça change concrètement

Un reverse proxy est un serveur placé entre les visiteurs et vos applications. Dans notre cas, Nginx reçoit les requêtes HTTP ou HTTPS venant d’Internet, puis les transmet à l’application correspondante sur le VPS. L’application peut donc continuer à tourner sur un port local, sans être directement exposée au public.

Sans reverse proxy, l’architecture ressemble souvent à ceci :

Internet → Port 3000 → Application Node.js en HTTP
Internet → Port 8000 → API Python en HTTP

Cette configuration peut fonctionner pour un test rapide, mais elle devient vite problématique. Les ports applicatifs sont visibles depuis Internet, le HTTPS n’est pas centralisé, et chaque service doit gérer une partie de la sécurité ou de la configuration réseau.

Avec Nginx comme reverse proxy, le schéma devient beaucoup plus propre :

Internet → Nginx port 443 HTTPS
              ├── app1.mondomaine.fr → localhost:3000
              └── app2.mondomaine.fr → localhost:8000

Le visiteur accède uniquement à une adresse claire, par exemple https://app1.mondomaine.fr. Nginx reçoit la requête sécurisée, puis la transmet en interne vers l’application qui écoute sur localhost:3000. Le port applicatif n’a pas besoin d’être ouvert publiquement.

Ce fonctionnement apporte plusieurs avantages importants pour un VPS.

Le rôle de Nginx est donc différent de celui d’un simple serveur web qui sert des fichiers HTML, CSS, images ou PHP. Dans cet article, nous l’utilisons comme reverse proxy : il reçoit les connexions entrantes, applique les règles de sécurité, gère le certificat SSL, puis transmet les requêtes vers une application déjà lancée en arrière-plan.

Cette approche est particulièrement utile pour les applications modernes : Node.js, Express, Next.js, API Python Flask ou FastAPI, services Docker, outils d’automatisation, tableaux de bord internes ou applications temps réel. Elle permet de garder une infrastructure propre, plus facile à sécuriser et plus simple à faire évoluer.

Pré-requis pour une bonne configuration Nginx reverse proxy VPS

Avant de commencer, vous devez disposer d’un VPS Linux avec un accès SSH administrateur. Les commandes de ce tutoriel sont pensées pour Debian 11/12 et Ubuntu 22.04/24.04, deux familles de distributions très utilisées pour héberger des applications web sur serveur.

Vous aurez besoin des éléments suivants :

• un VPS Linux avec accès root ou un utilisateur disposant des droits sudo ;
• un nom de domaine ou sous-domaine pointant vers l’adresse IP publique du VPS ;
• une application déjà lancée sur un port local, par exemple 127.0.0.1:3000 ;
• les ports 80 et 443 ouverts dans le pare-feu ;
• un accès au terminal SSH du serveur.

Le nom de domaine est indispensable si vous souhaitez obtenir un certificat SSL Let’s Encrypt avec Certbot. Par exemple, si vous voulez publier votre application sur app.mondomaine.fr, ce sous-domaine doit déjà pointer vers l’adresse IP du VPS via un enregistrement DNS de type A.

Vous pouvez vérifier la résolution DNS avec la commande suivante :

dig +short app.mondomaine.fr

La propagation DNS peut prendre jusqu’à 48 heures selon les cas, même si elle est généralement beaucoup plus rapide. Avant de demander un certificat SSL, prenez donc le temps de vérifier que le domaine pointe bien vers le serveur.

Vous devez aussi vérifier que les ports 80 et 443 sont ouverts. Le port 80 sert au trafic HTTP et à la validation initiale Let’s Encrypt. Le port 443 sert au trafic HTTPS.

Avec ufw, vous pouvez ouvrir ces ports ainsi :

ufw allow 80/tcp
ufw allow 443/tcp

Avec iptables, les commandes équivalentes sont :

iptables -A INPUT -p tcp --dport 80 -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -j ACCEPT

Enfin, assurez-vous que votre application backend fonctionne localement avant de configurer Nginx. Par exemple, si votre application Node.js écoute sur le port 3000, vous pouvez la tester depuis le serveur avec :

curl http://127.0.0.1:3000

Si cette commande ne répond pas correctement, le problème ne vient pas encore de Nginx. Il faut d’abord corriger le lancement de l’application, son port d’écoute ou son service système avant de mettre en place le reverse proxy. Avant de continuer, apprenez à sécuriser votre VPS avant d’exposer Nginx sur Internet.

Installer Nginx

La configuration se fait depuis le terminal SSH du VPS. Connectez-vous avec l’utilisateur root ou avec un compte disposant des droits sudo, puis commencez par mettre à jour la liste des paquets disponibles.

Sur Debian ou Ubuntu, l’installation de Nginx se fait avec apt :

apt update && apt install nginx -y

systemctl enable nginx systemctl start nginx

La commande apt update met à jour l’index des paquets. La commande apt install nginx -y installe Nginx sans demander de confirmation supplémentaire. Ensuite, systemctl enable nginx active le démarrage automatique du service au lancement du serveur, tandis que systemctl start nginx démarre immédiatement le service.

Vous pouvez vérifier que Nginx est bien installé avec :

nginx -v

La commande retourne la version installée, par exemple :

nginx version: nginx/1.18.0

Vérifiez ensuite l’état du service :

systemctl status nginx

Si tout est correct, le service doit apparaître comme actif, avec un statut proche de active (running). Vous pouvez aussi tester l’installation depuis un navigateur en saisissant l’adresse IP publique du VPS :

http://IP_DU_VPS

Si la page de bienvenue Nginx s’affiche, cela signifie que le serveur web répond correctement sur le port 80. Cette page n’est pas encore votre application : elle confirme simplement que Nginx est installé, démarré et joignable depuis Internet.

Avant de créer votre premier reverse proxy, il est utile de comprendre les principaux fichiers utilisés par Nginx.

Dans la plupart des cas, il est préférable de ne pas modifier directement le fichier global /etc/nginx/nginx.conf. Pour chaque application, créez plutôt un fichier dédié dans /etc/nginx/sites-available/, puis activez-le avec un lien symbolique dans /etc/nginx/sites-enabled/. Cette méthode permet de garder une configuration propre, lisible et facile à désactiver en cas de problème.

Configurer le premier reverse proxy (HTTP)

Avant d’ajouter le SSL, il est recommandé de configurer d’abord le reverse proxy en HTTP. Cette étape permet de vérifier que Nginx transmet correctement les requêtes vers l’application locale. Une fois le routage validé, vous pourrez ajouter HTTPS plus sereinement avec Certbot.

Dans cet exemple, nous partons du principe que votre application fonctionne sur le port 3000 du VPS et qu’elle est accessible localement à cette adresse :

http://127.0.0.1:3000

Créez un nouveau fichier de configuration Nginx pour cette application :

nano /etc/nginx/sites-available/monapp

Ajoutez ensuite la configuration suivante en remplaçant app.mondomaine.fr par votre propre domaine ou sous-domaine :

server {
    listen 80;
    server_name app.mondomaine.fr;

    location / {
        proxy_pass http://127.0.0.1:3000;
        proxy_http_version 1.1;
        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;
    }
}

Ce bloc indique à Nginx d’écouter les requêtes HTTP arrivant sur le port 80 pour le sous-domaine app.mondomaine.fr. Lorsqu’une requête arrive, Nginx la transmet à l’application locale via la directive proxy_pass.

Voici le rôle des principales directives utilisées :

Ces en-têtes sont importants. Sans eux, votre application peut voir toutes les requêtes comme venant de 127.0.0.1, ou ne pas savoir si l’utilisateur est arrivé via HTTP ou HTTPS. Certains frameworks utilisent aussi X-Forwarded-Proto pour générer les bonnes URL, appliquer des redirections ou sécuriser les cookies.

Une fois le fichier créé, activez le vhost avec un lien symbolique :

ln -s /etc/nginx/sites-available/monapp /etc/nginx/sites-enabled/

Avant de recharger Nginx, testez toujours la syntaxe :

nginx -t

Si la configuration est correcte, vous devez obtenir un résultat proche de celui-ci :

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

Vous pouvez alors recharger Nginx :

systemctl reload nginx

Le rechargement applique la nouvelle configuration sans arrêter brutalement le service. C’est préférable à un redémarrage complet, surtout sur un serveur qui héberge déjà plusieurs applications.

À ce stade, ouvrez votre navigateur et accédez à :

http://app.mondomaine.fr

Si tout est correctement configuré, Nginx doit afficher le contenu servi par votre application locale. En cas d’erreur, vérifiez d’abord que l’application tourne réellement sur le port indiqué dans proxy_pass, puis consultez les logs Nginx :

tail -f /var/log/nginx/error.log

Ne sautez pas l’étape nginx -t. Une simple accolade manquante, un point-virgule oublié ou une directive mal placée peut empêcher Nginx de recharger sa configuration et rendre vos applications inaccessibles.

Ajouter SSL avec Let’s Encrypt et Certbot

Votre reverse proxy fonctionne maintenant en HTTP. L’étape suivante consiste à ajouter un certificat SSL afin de rendre l’application accessible en HTTPS. Pour cela, nous allons utiliser Let’s Encrypt, une autorité de certification largement utilisée, et Certbot, l’outil qui automatise la demande, l’installation et le renouvellement du certificat.

Avec le plugin Nginx, Certbot peut détecter votre configuration, générer le certificat, modifier le vhost et ajouter automatiquement la redirection de HTTP vers HTTPS. C’est la méthode la plus simple pour sécuriser rapidement une application exposée derrière Nginx.

Avant de lancer la commande, vérifiez une dernière fois que le domaine pointe bien vers l’IP du VPS et que le port 80 est ouvert. Let’s Encrypt doit pouvoir joindre votre serveur pour valider le domaine.

1. Installer Certbot avec le plugin Nginx

Installez Certbot et son plugin Nginx avec la commande suivante :

apt install certbot python3-certbot-nginx -y

Le paquet certbot fournit l’outil principal de génération et de renouvellement des certificats. Le paquet python3-certbot-nginx permet à Certbot de lire et modifier automatiquement la configuration Nginx.

Une fois l’installation terminée, vous pouvez vérifier que Certbot est disponible avec :

certbot --version

Si la commande retourne une version, l’outil est prêt. Vous pouvez alors passer à la demande du certificat SSL pour votre domaine ou sous-domaine.

2. Obtenir et configurer le certificat automatiquement

Une fois Certbot installé, vous pouvez demander un certificat SSL pour votre domaine. Dans notre exemple, l’application est accessible via app.mondomaine.fr. La commande à exécuter est donc :

certbot --nginx -d app.mondomaine.fr

Remplacez bien app.mondomaine.fr par votre propre domaine ou sous-domaine.

Certbot va alors effectuer plusieurs actions automatiquement. Il vérifie d’abord que le domaine pointe bien vers l’adresse IP de votre VPS. Cette étape est indispensable : si le DNS n’est pas correctement configuré, la génération du certificat échouera.

Ensuite, Certbot demande un certificat Let’s Encrypt pour le domaine indiqué. Il analyse aussi la configuration Nginx existante afin de trouver le bloc server correspondant à app.mondomaine.fr. Avec le plugin Nginx, il peut modifier directement ce fichier pour ajouter l’écoute HTTPS sur le port 443, déclarer les chemins vers les certificats SSL et configurer une redirection automatique de HTTP vers HTTPS.

Pendant l’exécution, Certbot peut vous demander une adresse e-mail, puis vous proposer d’accepter les conditions d’utilisation de Let’s Encrypt. Selon la version utilisée, il peut aussi demander si vous souhaitez activer la redirection automatique vers HTTPS. Pour un site ou une application en production, cette redirection est fortement recommandée.

À la fin de l’opération, votre application doit être accessible avec une URL sécurisée :

https://app.mondomaine.fr

Dans le navigateur, vous devez voir le cadenas HTTPS à côté de l’adresse. Cela confirme que Nginx sert désormais l’application via un certificat SSL valide.

3. Vérifier le renouvellement automatique

Les certificats Let’s Encrypt ont une durée de validité limitée. Certbot configure généralement un mécanisme de renouvellement automatique via systemd ou via une tâche planifiée. Il est toutefois important de vérifier que ce renouvellement fonctionne correctement dès l’installation.

Pour simuler un renouvellement sans modifier les certificats existants, utilisez la commande suivante :

certbot renew --dry-run

L’option --dry-run lance un test complet de renouvellement. Elle permet de vérifier que Certbot peut contacter Let’s Encrypt, valider le domaine et recharger correctement la configuration si nécessaire.

Si le test se termine sans erreur, le renouvellement automatique est correctement configuré. Vous pouvez aussi consulter la liste des certificats installés avec :

certbot certificates

Cette commande affiche les domaines couverts, les chemins des certificats et leur date d’expiration. Elle est utile pour contrôler rapidement l’état de vos certificats SSL, surtout si vous hébergez plusieurs applications ou sous-domaines sur le même VPS.

En cas d’erreur pendant le dry-run, vérifiez en priorité que le domaine pointe toujours vers le VPS, que le port 80 reste ouvert et que la configuration Nginx ne contient pas d’erreur de syntaxe.

4. Configuration Nginx après Certbot (annotée)

Après l’exécution de Certbot, le fichier /etc/nginx/sites-available/monapp est généralement modifié automatiquement. La configuration finale ressemble à ceci :

server {
    listen 80;
    server_name app.mondomaine.fr;

    return 301 https://$host$request_uri;
}

server {
    listen 443 ssl;
    server_name app.mondomaine.fr;

    ssl_certificate     /etc/letsencrypt/live/app.mondomaine.fr/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/app.mondomaine.fr/privkey.pem;

    include /etc/letsencrypt/options-ssl-nginx.conf;
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem;

    location / {
        proxy_pass http://127.0.0.1:3000;
        proxy_http_version 1.1;
        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;
    }
}

Le premier bloc server écoute sur le port 80. Son seul rôle est de rediriger toutes les requêtes HTTP vers l’équivalent HTTPS. Ainsi, un visiteur qui saisit http://app.mondomaine.fr est automatiquement envoyé vers https://app.mondomaine.fr.

Le second bloc server écoute sur le port 443 avec l’option ssl. C’est lui qui sert réellement l’application en HTTPS. Les directives ssl_certificate et ssl_certificate_key indiquent les chemins des certificats générés par Let’s Encrypt.

Les lignes suivantes sont ajoutées pour appliquer les paramètres SSL recommandés par Certbot :

include /etc/letsencrypt/options-ssl-nginx.conf;
ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem;

Le bloc location / reste très proche de la configuration HTTP initiale. Nginx continue de transmettre les requêtes vers l’application locale sur 127.0.0.1:3000, mais l’utilisateur, lui, communique uniquement avec Nginx en HTTPS.

Après toute modification manuelle, testez toujours la configuration :

nginx -t

Puis rechargez Nginx uniquement si le test est valide :

systemctl reload nginx

Ajouter les headers de sécurité

Une fois le reverse proxy disponible en HTTPS, vous pouvez renforcer la sécurité côté navigateur grâce aux headers HTTP. Ces en-têtes sont envoyés par Nginx avec les réponses du serveur. Ils indiquent au navigateur comment se comporter face à certains risques : chargement en HTTP, intégration dans une iframe, détection MIME incorrecte ou transmission du référent.

Les headers de sécurité s’ajoutent dans le bloc server HTTPS de votre vhost Nginx :

server {
    listen 443 ssl;
    server_name app.mondomaine.fr;

    ssl_certificate     /etc/letsencrypt/live/app.mondomaine.fr/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/app.mondomaine.fr/privkey.pem;

    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
    add_header X-Frame-Options           DENY                                   always;
    add_header X-Content-Type-Options    nosniff                                always;
    add_header Referrer-Policy           "no-referrer-when-downgrade"           always;
    add_header X-XSS-Protection          "1; mode=block"                        always;

    location / {
        proxy_pass http://127.0.0.1:3000;
        proxy_http_version 1.1;
        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;
    }
}

Voici le rôle des principaux headers utilisés :

Le header le plus sensible est Strict-Transport-Security, aussi appelé HSTS. Dans l’exemple ci-dessus, la directive max-age=31536000 demande au navigateur d’utiliser HTTPS pendant un an. L’option includeSubDomains applique aussi cette règle à tous les sous-domaines.

Soyez prudent avec cette option. Si certains sous-domaines de votre domaine fonctionnent encore uniquement en HTTP, ils pourraient devenir inaccessibles pour les navigateurs ayant reçu cette règle HSTS. Avant d’activer includeSubDomains, vérifiez donc que l’ensemble de vos sous-domaines importants sont bien disponibles en HTTPS.

Après avoir ajouté ces headers, testez la configuration Nginx :

nginx -t
systemctl reload nginx

Vous pouvez ensuite vérifier les headers envoyés avec curl :

curl -I https://app.mondomaine.fr

La réponse doit afficher les en-têtes configurés. Si ce n’est pas le cas, vérifiez que les directives add_header sont placées dans le bon bloc server et que Nginx a bien été rechargé après modification.

Héberger plusieurs applications sur le même VPS

L’un des grands avantages d’un reverse proxy Nginx est de pouvoir héberger plusieurs applications sur le même VPS, chacune avec son propre domaine ou sous-domaine. Vous pouvez par exemple publier une application Node.js sur app.mondomaine.fr et une API Python sur api.mondomaine.fr, tout en utilisant le même serveur, la même adresse IP et le même Nginx.

Le principe est simple : chaque application dispose de son propre fichier de configuration dans /etc/nginx/sites-available/, puis chaque fichier est activé dans /etc/nginx/sites-enabled/.

Créons un second vhost pour une API qui tourne localement sur le port 8000 :

nano /etc/nginx/sites-available/monapideux

Ajoutez la configuration suivante :

server {
    listen 80;
    server_name api.mondomaine.fr;

    location / {
        proxy_pass http://127.0.0.1:8000;
        proxy_http_version 1.1;
        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;
    }
}

Activez ensuite ce nouveau vhost :

ln -s /etc/nginx/sites-available/monapideux /etc/nginx/sites-enabled/

Testez la configuration :

nginx -t

Si le test est valide, vous pouvez demander un certificat SSL pour ce second sous-domaine :

certbot --nginx -d api.mondomaine.fr

Puis rechargez Nginx si nécessaire :

systemctl reload nginx

Vous obtenez alors une architecture claire :

app.mondomaine.fr  → HTTPS → 127.0.0.1:3000
api.mondomaine.fr  → HTTPS → 127.0.0.1:8000

Chaque application reste isolée sur son propre port local, tandis que les visiteurs accèdent uniquement aux sous-domaines publics en HTTPS. Cette organisation est plus simple à maintenir que l’ouverture directe de plusieurs ports applicatifs sur Internet.

Pour vérifier les vhosts actifs, vous pouvez lister le contenu du dossier sites-enabled :

ls -l /etc/nginx/sites-enabled/

Cette commande permet de voir rapidement quelles configurations sont actuellement activées dans Nginx.

Besoin d’un serveur VPS KVM performant et flexible ?

Découvrez nos offres VPS KVM haut de gamme : des ressources garanties et un contrôle total pour vos projets. Profitez d’un hébergement 100 % SSD, d’un accès root complet, le tout dans un datacenter en France. Démarrez dès maintenant à partir de 4,99 €/mois !

Je choisis mon VPS KVM

Cas avancés

La configuration précédente couvre le cas le plus courant : une application locale exposée derrière Nginx avec HTTPS. Dans la pratique, vous pouvez aussi utiliser Nginx comme reverse proxy devant un container Docker, une application temps réel utilisant WebSocket ou plusieurs services accessibles depuis des chemins différents sur un même domaine.

Les exemples suivants reprennent la même logique : Nginx reste le point d’entrée public, puis transmet les requêtes vers le service interne adapté. Ces cas demandent simplement quelques directives supplémentaires.

1. Reverse proxy devant Docker

Si votre application tourne dans un container Docker, vous pouvez aussi la publier derrière Nginx. Le cas le plus simple consiste à exposer le port du container sur l’adresse locale du VPS.

Par exemple, si votre container écoute sur le port 8080, la configuration Nginx peut ressembler à ceci :

location / {
    proxy_pass http://127.0.0.1:8080;
    proxy_http_version 1.1;
    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;
}

Dans ce cas, Docker publie le service sur le port 8080 du VPS, et Nginx se charge de l’exposer proprement via HTTPS.

Si le container n’est pas exposé sur localhost, mais uniquement disponible sur un réseau Docker interne, vous pouvez cibler son adresse IP dans le réseau bridge :

proxy_pass http://172.17.0.2:8080;

Cette méthode fonctionne, mais elle peut être moins pratique, car l’adresse IP d’un container peut changer après un redémarrage. Avec Docker Compose, la méthode recommandée consiste plutôt à créer un réseau partagé entre le service Nginx et l’application, puis à utiliser le nom du service Docker comme hôte interne.

Dans tous les cas, évitez d’exposer inutilement les ports applicatifs sur Internet. L’idéal est de laisser Nginx recevoir le trafic public en 80/443, puis de limiter les communications backend au réseau local ou au réseau Docker privé.

2. Support WebSocket

Certaines applications web utilisent WebSocket pour maintenir une connexion persistante entre le navigateur et le serveur. C’est le cas des applications temps réel, des interfaces de chat, de certains tableaux de bord, de Socket.IO, de Next.js, de n8n ou encore de services qui diffusent des événements en continu.

Avec une configuration reverse proxy classique, les requêtes HTTP simples fonctionnent, mais les connexions WebSocket peuvent échouer ou se couper rapidement. Pour les prendre en charge correctement, il faut transmettre les en-têtes Upgrade et Connection au backend.

Voici un exemple de configuration compatible WebSocket :

location / {
    proxy_pass http://127.0.0.1:3000;
    proxy_http_version 1.1;

    proxy_set_header Upgrade    $http_upgrade;
    proxy_set_header Connection "upgrade";

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

La directive proxy_http_version 1.1 est importante, car WebSocket repose sur une mise à niveau de la connexion HTTP. Les lignes proxy_set_header Upgrade $http_upgrade; et proxy_set_header Connection "upgrade"; indiquent à Nginx de transmettre cette demande de mise à niveau à l’application backend.

La directive proxy_read_timeout 86400 permet de conserver une connexion ouverte plus longtemps. Sans ce réglage, certaines connexions persistantes peuvent être interrompues après un délai trop court, ce qui provoque des déconnexions visibles côté utilisateur.

Si votre application temps réel se déconnecte après quelques secondes ou quelques minutes, vérifiez donc en priorité la présence de ces directives dans le bloc location.

3. Routage par chemin (path-based routing)

Jusqu’ici, chaque application utilise son propre sous-domaine : app.mondomaine.fr, api.mondomaine.fr, etc. Il existe une autre approche : le routage par chemin. Dans ce cas, plusieurs applications sont accessibles depuis le même domaine, mais avec des chemins différents.

Par exemple :

https://mondomaine.fr/app1/
https://mondomaine.fr/api/

Cette méthode peut être utile pour regrouper plusieurs services derrière un seul nom de domaine. Nginx utilise alors plusieurs blocs location pour savoir vers quelle application transmettre chaque requête.

Voici un exemple de configuration :

server {
    listen 443 ssl;
    server_name mondomaine.fr;

    ssl_certificate     /etc/letsencrypt/live/mondomaine.fr/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/mondomaine.fr/privkey.pem;

    location /app1/ {
        proxy_pass http://127.0.0.1:3000/;
        proxy_http_version 1.1;
        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;
    }

    location /api/ {
        proxy_pass http://127.0.0.1:8000/;
        proxy_http_version 1.1;
        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;
    }
}

Dans cet exemple, les requêtes vers /app1/ sont envoyées vers l’application locale sur le port 3000, tandis que les requêtes vers /api/ sont transmises au service local sur le port 8000.

Attention toutefois : le routage par chemin peut nécessiter une configuration spécifique côté application. Certaines applications supposent qu’elles sont servies depuis la racine du domaine, c’est-à-dire /. Si vous les placez derrière /app1/, les liens internes, les fichiers CSS, les scripts JavaScript ou les redirections peuvent mal fonctionner.

Quand c’est possible, l’utilisation de sous-domaines reste souvent plus simple à maintenir :

app.mondomaine.fr
api.mondomaine.fr

Le routage par chemin est pratique, mais il doit être testé avec soin, surtout pour les applications qui génèrent automatiquement leurs URL.

Vérification du bon fonctionnement

Après avoir configuré Nginx, le reverse proxy, le certificat SSL et les éventuels headers de sécurité, il est important de vérifier chaque point avant de considérer la mise en production comme terminée.

Commencez par tester la syntaxe de Nginx :

nginx -t

Le résultat attendu est le suivant :

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

Vérifiez ensuite que le service Nginx est bien actif :

systemctl status nginx

Le statut doit indiquer active (running). Si Nginx n’est pas démarré, vous pouvez le lancer avec :

systemctl start nginx

Testez ensuite l’accès HTTPS depuis un navigateur :

https://app.mondomaine.fr

La page de votre application doit s’afficher, avec un cadenas HTTPS visible dans la barre d’adresse.

Vous pouvez aussi vérifier les headers HTTP avec curl :

curl -I https://app.mondomaine.fr

Cette commande doit retourner une réponse contenant les informations du serveur, le statut HTTP, ainsi que les headers de sécurité ajoutés dans la configuration Nginx.

Testez ensuite la redirection HTTP vers HTTPS :

curl -I http://app.mondomaine.fr

La réponse doit indiquer une redirection permanente, généralement avec un code 301, vers l’URL HTTPS.

Contrôlez également le renouvellement SSL :

certbot renew --dry-run

Enfin, consultez les logs pour vérifier que Nginx reçoit bien les requêtes et qu’aucune erreur liée au proxy n’apparaît :

tail -f /var/log/nginx/access.log
tail -f /var/log/nginx/error.log

Si les accès apparaissent dans access.log et qu’aucune erreur critique ne remonte dans error.log, votre reverse proxy est correctement opérationnel.

Erreurs fréquentes et cas de blocage

Même avec une configuration correcte, certaines erreurs peuvent apparaître lors de la mise en place d’un reverse proxy Nginx. La plus connue est l’erreur 502 Bad Gateway. Elle signifie généralement que Nginx fonctionne, mais qu’il ne parvient pas à joindre l’application backend indiquée dans proxy_pass.

Voici les problèmes les plus fréquents et les vérifications à effectuer.

Pour diagnostiquer une erreur 502 Bad Gateway, commencez par vérifier que l’application backend répond localement :

curl http://127.0.0.1:3000

Si cette commande échoue, le problème vient de l’application, pas de Nginx. Vérifiez alors le processus, le port d’écoute, les logs applicatifs ou le service systemd associé.

Vous pouvez aussi identifier les ports réellement ouverts sur le VPS avec :

ss -tlnp

Cette commande permet de voir si une application écoute bien sur 127.0.0.1:3000, 127.0.0.1:8000 ou un autre port.

En cas d’erreur Nginx, consultez toujours le journal dédié :

tail -f /var/log/nginx/error.log

Les messages y sont souvent explicites : port refusé, hôte introuvable, permission insuffisante, timeout ou erreur de configuration. Une lecture attentive du log permet généralement d’identifier rapidement la cause du blocage.

Bonnes pratiques

Avant toute modification importante sur un serveur en production, commencez par sauvegarder votre VPS avant toute modification de configuration Nginx. Sur un VPS KVM LWS, l’utilisation d’un snapshot permet de revenir rapidement à un état stable si une erreur de configuration rend Nginx inaccessible ou perturbe vos applications. C’est une précaution simple, mais très utile avant de modifier un vhost, d’ajouter SSL ou de revoir les règles de pare-feu.

Il est aussi recommandé de séparer chaque application dans son propre fichier de configuration. Évitez de tout placer dans /etc/nginx/nginx.conf. Ce fichier doit rester réservé à la configuration globale de Nginx. Pour vos applications, utilisez plutôt cette organisation :

/etc/nginx/sites-available/monapp
/etc/nginx/sites-available/api
/etc/nginx/sites-available/admin

Puis activez uniquement les configurations nécessaires avec des liens symboliques dans /etc/nginx/sites-enabled/.

Pensez également à désactiver le vhost par défaut si vous ne l’utilisez pas :

rm /etc/nginx/sites-enabled/default
nginx -t
systemctl reload nginx

Cette action évite que la page de bienvenue Nginx reste accessible depuis l’adresse IP du VPS ou qu’un domaine non configuré tombe sur un contenu générique.

Autre règle importante : testez toujours la configuration avant de recharger Nginx.

nginx -t

Si le test échoue, ne lancez pas systemctl reload nginx. Lisez d’abord le message d’erreur, corrigez le fichier concerné, puis relancez le test.

Vous pouvez aussi activer la compression gzip pour améliorer les performances sur les réponses texte, JSON ou CSS :

gzip on;
gzip_types text/plain text/css application/json application/javascript application/xml;

Placez cette configuration dans le bloc server ou dans la configuration globale si vous souhaitez l’appliquer à plusieurs vhosts.

Surveillez régulièrement les logs, surtout après une mise en production :

tail -f /var/log/nginx/access.log
tail -f /var/log/nginx/error.log

Le fichier access.log permet de suivre les requêtes entrantes. Le fichier error.log aide à identifier les erreurs de proxy, les timeouts, les problèmes de certificats ou les erreurs de syntaxe.

Enfin, contrôlez périodiquement vos certificats Let’s Encrypt :

certbot certificates

Cette commande affiche les certificats installés, leurs domaines associés et leur date d’expiration. Pour limiter les risques, pensez aussi à sauvegarder votre VPS avant toute modification importante de configuration Nginx. Vous pouvez vous appuyer sur une stratégie de sauvegarde sur VPS et renforcer la sécurité de votre serveur, notamment avant d’exposer une nouvelle application sur Internet.

Pour les profils avancés, un outil d’assistance au développement peut également aider à relire une configuration complexe. Par exemple, vous pouvez analyser et optimiser votre configuration Nginx avec Claude Code dans le cadre d’un workflow d’administration plus technique.

FAQ

Qu’est-ce qu’un reverse proxy Nginx et à quoi ça sert sur un VPS ?

Un reverse proxy Nginx sert d’intermédiaire entre les visiteurs et les applications hébergées sur votre VPS. Il reçoit les requêtes en HTTP ou HTTPS, puis les transmet à une application locale, par exemple sur 127.0.0.1:3000. Cela permet de centraliser le SSL, de masquer les ports applicatifs et d’héberger plusieurs services derrière une seule adresse IP.

Quelle est la différence entre proxy_pass et un serveur web classique avec Nginx ?

Avec un serveur web classique, Nginx sert directement des fichiers statiques ou transmet des fichiers PHP à un moteur comme PHP-FPM. Avec proxy_pass, Nginx ne sert pas directement l’application : il relaie les requêtes vers un backend déjà lancé, comme une application Node.js, Python, Docker ou une API.

Comment héberger plusieurs sites sur le même VPS avec Nginx ?

Il suffit de créer un vhost par domaine ou sous-domaine dans /etc/nginx/sites-available/, puis de l’activer dans /etc/nginx/sites-enabled/. Chaque vhost peut rediriger vers un port local différent, par exemple app.mondomaine.fr vers 127.0.0.1:3000 et api.mondomaine.fr vers 127.0.0.1:8000.

Le certificat Let’s Encrypt se renouvelle-t-il automatiquement avec Certbot ?

Oui, Certbot configure généralement un renouvellement automatique via systemd ou une tâche planifiée. Il est conseillé de vérifier son bon fonctionnement avec la commande certbot renew --dry-run.

Nginx reverse proxy fonctionne-t-il avec Docker ?

Oui. Nginx peut transmettre les requêtes vers un container Docker exposé sur un port local, par exemple 127.0.0.1:8080. Avec Docker Compose, il est aussi possible d’utiliser un réseau partagé entre Nginx et les services applicatifs.

Comment diagnostiquer une erreur 502 Bad Gateway avec Nginx ?

Une erreur 502 Bad Gateway signifie souvent que Nginx ne parvient pas à joindre l’application backend. Vérifiez d’abord que l’application tourne bien avec curl http://127.0.0.1:3000, puis contrôlez les ports ouverts avec ss -tlnp et consultez /var/log/nginx/error.log.

Conclusion

Configurer Nginx comme reverse proxy sur un VPS Linux permet de publier une ou plusieurs applications de manière propre, sécurisée et évolutive. Au lieu d’exposer directement des ports applicatifs comme 3000, 8000 ou 8080, vous centralisez les accès via Nginx, avec HTTPS, redirection automatique, headers de sécurité et logs dédiés.😊 Cette architecture convient aussi bien à une application Node.js qu’à une API Python, un container Docker ou plusieurs services hébergés sur le même VPS. En respectant les bonnes pratiques essentielles : test systématique avec nginx -t, sauvegarde avant modification, vhosts séparés, surveillance des logs et vérification des certificats, vous disposez d’une base solide pour administrer vos applications web en production.✨

Besoin d’un serveur VPS KVM performant et flexible ?

Découvrez nos offres VPS KVM haut de gamme : des ressources garanties et un contrôle total pour vos projets. Profitez d’un hébergement 100 % SSD, d’un accès root complet, le tout dans un datacenter en France. Démarrez dès maintenant à partir de 4,99 €/mois !

Je choisis mon VPS KVM

Vous avez une question, une difficulté avec votre configuration Nginx ou une astuce à partager ? N’hésitez pas à laisser un commentaire sous cet article pour échanger avec la communauté LWS.