Proxy inverse Nginx avec SSL

Si vous exécutez une application Web sur un port privé (comme LocalHost: 3000), il n'est pas directement accessible sur Internet.L'un des moyens les plus efficaces d'exposer en toute sécurité l'application est de mettre un proxy inversé devant lui.

Nginx est un outil bien connu léger qui peut faire exactement cela - recevoir un trafic entrant et le transmettre à votre application - tout en gérant les HTTP avec un certificat SSL gratuit de Let's Encrypt.

Dans ce guide, vous apprendrez à:

• Configurez Nginx en tant que proxy inverse pour un service Web interne
  
• Sécurochez-le avec un certificat SSL à l'aide de CERTBOT
  
• Comprenez chaque partie de la configuration afin que vous sachiez ce qu'elle fait et pourquoi

Nouveau sur les serveurs Web?Découvrez notre explication sur Comment fonctionnent les serveurs Web.

Qu'est-ce qu'un proxy inversé et pourquoi en utiliser un?

UNE proxy inversé est un serveur qui se trouve entre vos utilisateurs et vos services backend.Au lieu que votre application écoute publiquement sur un port (comme 3000), Nginx reçoit d'abord le trafic, puis le transmet à l'application en arrière-plan.

Voici pourquoi cette approche est si utile:

• Cache les ports et services internes
  Votre application n'a pas besoin d'être exposée directement au public.Cela réduit la surface d'attaque et vous aide à contrôler l'accès.
  
• Gère https pour vous
  De nombreux cadres Web peuvent servir les HTTP directement, mais il est souvent plus facile et plus fiable de laisser Nginx le faire - en particulier lors de l'utilisation de certificats SSL gratuits de Let's Encrypt.
  
• Active l'hébergement de plusieurs services sur un seul serveur
  Vous pouvez exécuter plusieurs applications sur différents ports (comme 3000, 4000, 5000) et le trafic d'itinérance en fonction du domaine ou du chemin en utilisant une seule adresse IP publique.
  
• Améliore l'exploitation forestière et la surveillance
  Nginx vous donne des journaux d'accès et d'erreur centralisés, il est donc plus facile de surveiller les performances ou d'étudier les problèmes.
  
• Fournit une mise en cache en option, l'équilibrage de la charge et la limitation des taux
  Vous pouvez optimiser le flux de trafic et protéger les services backend avec seulement quelques lignes supplémentaires dans votre configuration Nginx.

Même si votre application peut déjà gérer le trafic Web, l'utilisation de Nginx comme proxy inverse simplifie souvent la configuration, améliore la flexibilité et augmente le contrôle.

Conditions préalables

Avant de commencer, assurez-vous d'avoir tout ce dont vous avez besoin:

• Un VPS ou un serveur cloud exécutant Ubuntu 20.04 ou version ultérieure: La plupart des commandes et des versions de package utilisées dans ce tutoriel supposent un système basé sur Debian.Alors que Nginx et CERTBOT fonctionnent sur d'autres distributions, le processus de configuration peut différer.
• Accès racine ou sudo: Vous installerez des packages, modifierez les fichiers système et redémarrez les services - qui nécessitent tous des privilèges élevés.
• Un nom de domaine enregistré: Vous en aurez besoin pour demander un certificat SSL.Saisissons valider la propriété de votre domaine avant de délivrer un certificat.Sans DNS pointé vers votre serveur, la validation échouera.
• DNS pointant vers l'IP publique de votre serveur: Assurez-vous que les enregistrements DNS de votre domaine sont mis à jour.Un simple enregistrement pointant vers l'IP de votre serveur est suffisant:

A yourdomain.com → 123.123.123.123
A www.yourdomain.com → 123.123.123.123

La propagation peut prendre quelques minutes à quelques heures.

Vous ne savez pas comment configurer votre DNS?Voici Comment ajouter un enregistrement avec la plupart des hôtes de domaine.

• Une application exécutée sur localhost (par exemple, http://localhost:3000): Ceci est l'application que vous vous proxiez.Cela pourrait être n'importe quoi - Node.js, Python Flask, Ruby on Rails, etc. Tant qu'il écoute sur un port local, vous pouvez le procurer.

Remarque: Si votre application n'est pas encore en cours d'exécution, ce n'est pas grave - vous pouvez toujours passer par la configuration et tester plus tard.

• Nginx installé: Nginx servira de serveur orienté public.S'il n'est pas encore installé:

sudo apt update
sudo apt install nginx

Vérifiez ensuite qu'il fonctionne:

sudo systemctl status nginx

Vous devriez voir "actif (en cours d'exécution)".

• CERTBOT installé avec le plugin Nginx: CERTBOT automatise le processus d'obtention et de renouvellement des certificats SSL de Let's Encrypt.Installez-le comme ceci:

sudo apt install certbot python3-certbot-nginx

Ce plugin permet de modifier automatiquement votre configuration Nginx lorsque vous demandez un certificat - aucune modification manuelle requise pour les configurations de base.

Vous avez un autre système d'exploitation?Suivez ce guide sur Comment installer, cryptons sur Fedora et Debian

Étape 1: Configurez le proxy inverse Nginx

Maintenant que votre système est prêt, la première étape réelle consiste à configurer Nginx pour écouter le trafic sur votre domaine et à le transmettre à votre application interne - c'est ce qui fait agir Nginx comme un proxy inverse.

Pourquoi cela compte

Sans cette configuration, les utilisateurs essayant de visiter votre site Web appuyeraient sur une page vide ou l'écran de bienvenue Nginx par défaut.Vous devez dire explicitement Nginx:

• À quel (s) domaine (s) il devrait répondre
  
• Que faire avec les demandes entrantes
  
• Où envoyer le trafic dans les coulisses

Créer un nouveau bloc de serveur

Vous créerez un fichier de configuration pour votre domaine dans le répertoire disponible des sites de Nginx.Cela maintient les configurations organisées et facilite l'activation ou la désactivation des sites individuels.

sudo nano /etc/nginx/sites-available/yourdomain.com

Collez dans le bloc suivant, en ajustant le domaine et le port d'application au besoin:

server {
    listen 80;
    server_name yourdomain.com www.yourdomain.com;

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

        # Pass important headers to the backend
        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 que fait cette configuration

• Écoutez 80;
  Dit à Nginx d'écouter le trafic HTTP sur le port 80.
  
• server_name yourDomain.com www.yourdomain.com;
  Correspond à ce bloc aux demandes faites à votre domaine.Vous pouvez ajouter ou supprimer des sous-domaines selon les besoins.
  
• emplacement /
  Attrape toutes les demandes de la racine et les transmet à votre application.
  
• proxy_pass http: // localhost: 3000;
  C'est le cœur du proxy inversé - il envoie la demande à votre application backend en cours d'exécution sur le port 3000.
  
• lignes proxy_set_header
  Ceux-ci préservent les détails de la demande du client d'origine, comme:
  
  • L'adresse IP de l'utilisateur (X-REAL-IP)
    
  • Le protocole d'origine (HTTP ou HTTPS)
    
  • Le nom d'hôte original
    
• Ces informations sont utiles pour la journalisation, l'analyse ou lorsque votre application doit générer des URL qui correspondent à l'expérience du visiteur.

Activer la configuration

Nginx utilise des liens symboliques dans le compatible avec les sites Répertoire pour activer les sites.Alors maintenant, vous créez un lien et recharger Nginx:

sudo ln -s /etc/nginx/sites-available/yourdomain.com /etc/nginx/sites-enabled/
sudo nginx -t

Vérifiez les erreurs de syntaxe.Si tout semble bon:

sudo systemctl reload nginx

Votre proxy inversé est maintenant en direct - demande à http://yourdomain.com sera transmis à votre application sur le port 3000.

Étape 2: Ajouter SSL avec Let's Encrypt and Certbot

Avec le proxy inversé fonctionnant sur HTTP, l'étape suivante consiste à le sécuriser avec HTTPS.Cela ajoute du cryptage à toutes les communications entre vos utilisateurs et votre serveur - protégeant les informations d'identification de connexion, les demandes d'API, les données personnelles, etc.

Vous utiliserez Let's Encrypt, une autorité de certificat gratuite, et CERTBOT, qui automatise le processus.

Pourquoi HTTPS est important

• Crypte le trafic Personne ne peut l'intercepter ou le falsifier
  
• Améliore le référencement - Les moteurs de recherche préfèrent les sites sécurisés
  
• Renforce la confiance - Les utilisateurs s'attendent à voir l'icône de cadenas
  
• Requis pour de nombreuses API, connexions et systèmes de paiement

Demander le certificat

Exécutez cette commande, en remplaçant les domaines par vos valeurs réelles:

sudo certbot --nginx -d yourdomain.com -d www.yourdomain.com

Ce que cela fait:

• Certe à utiliser le plugin Nginx
  
• Spécifie les domaines pour lesquels vous demandez un certificat pour

Certbot Will:

• Effectuez la validation du domaine en créant un fichier temporaire dans votre configuration nginx
  
• Contactez-le, cryptant pour vérifier la propriété du domaine
  
• Téléchargez votre certificat SSL et votre clé privée
  
• Modifiez votre configuration Nginx pour utiliser HTTPS
  
• Rediriger éventuellement tout le trafic HTTP vers HTTPS

Conseil: Si votre DNS n'est pas entièrement propagé ou que votre serveur Blocks Port 80, la validation échouera.Vous pouvez tester cela avec:

curl -I http://yourdomain.com

Pour mieux comprendre les ports, consultez notre guide sur Comment fonctionnent les ports du serveur Web.

Vérifiez les modifications

Une fois le certificat terminé, votre configuration Nginx devrait inclure quelque chose comme ceci:

listen 443 ssl;
ssl_certificate /etc/letsencrypt/live/yourdomain.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/yourdomain.com/privkey.pem;

Vous devriez maintenant pouvoir visiter https://yourdomain.com et voir votre site avec un certificat SSL valide.

Facultatif: force HTTPS

Si vous n'avez pas choisi l'option de redirection lors de la configuration de certificat, vous pouvez l'ajouter manuellement:

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

Cela oblige tous les trafics HTTP à rediriger vers HTTPS, ce qui garantit que les utilisateurs n'utilisent pas accidentellement la version non sécurisée de votre site.

Étape 3: Améliorer les paramètres SSL (recommandés pour la production)

Une fois votre certificat SSL en place, vous pouvez affiner Nginx pour améliorer la sécurité et la compatibilité.Ces paramètres vont dans le bloc HTTPS Server.

Voici un exemple amélioré:

ssl_protocols TLSv1.2 TLSv1.3;
ssl_prefer_server_ciphers on;
ssl_ciphers HIGH:!aNULL:!MD5;
ssl_session_cache shared:SSL:10m;
ssl_session_timeout 10m;
ssl_session_tickets off;

Ce que font ces paramètres

• ssl_protocols TLSv1.2 TLSv1.3
  Désactive des protocoles plus anciens et moins sécurisés comme TLS 1.0 et 1.1.
  
• ssl_prefer_server_ciphers sur
  Permet à votre serveur de décider de l'algorithme de chiffrement, plutôt que de reporter au navigateur - ce qui peut réduire l'exposition aux attaques de chiffrement faibles.
  
• SSL_CIPHERS HIGH :! Anull :! MD5
  Spécifie des suites de chiffres solides et exclut les suites faibles ou cassées (comme les chiffres MD5 et nuls).
  
• ssl_session_cache et ssl_session_timeout
  Contrôler la réutilisation de la session SSL, ce qui peut légèrement améliorer les performances sans compromettre la sécurité.
  
• SSL_SESSES_TICKETS
  Désactive les billets de session, ce qui peut être un problème de sécurité s'il n'est pas tourné régulièrement.

Ces changements améliorent votre score de sécurité SSL et protègent les visiteurs contre les attaques de rétrogradation ou les choix de cryptage sans sécurité.

Optionnelle: Vous pouvez tester votre site avec SSL Labs pour voir comment votre configuration fonctionne et obtenir des suggestions d'amélioration spécifiques.

Étape 4: (Facultatif) Ajouter des paramètres diffie-hellman

Pour un chiffrement encore plus fort, vous pouvez générer une touche Diffie-Hellman (DH) personnalisée.Cette étape est facultative, mais elle est souvent recommandée pour les environnements de production.

Exécutez cette commande pour générer un groupe DH 2048 bits:

sudo openssl dhparam -out /etc/ssl/certs/dhparam.pem 2048

Ajoutez ensuite la ligne suivante à votre bloc SSL Server:

ssl_dhparam /etc/ssl/certs/dhparam.pem;

Pourquoi ajouter ceci?

Les paramètres Diffie-Hellman renforcent secret, ce qui signifie que même si votre clé privée est en quelque sorte compromise à l'avenir, les séances cryptées passées seront toujours sécurisées.

Il faut quelques minutes pour générer le groupe DH, mais c'est une étape unique et vaut la peine d'être fait pour une meilleure posture de sécurité.

Étape 5: Configurez l'auto-renouvellement pour les certificats SSL

Les certificats de crypte expirent tous les 90 jours.Heureusement, CERTBOT installe une minuterie de système qui vérifie deux fois par jour pour les certificats en raison de l'expiration et des renouvellements automatiquement.

Vous pouvez confirmer que la minuterie est active avec:

sudo systemctl list-timers | grep certbot

Vous devriez voir quelque chose comme ceci:

NEXT                         LEFT    LAST                         PASSED  UNIT           ACTIVATES
2025-06-19 04:00:00 UTC      12h     2025-06-18 04:00:00 UTC       11h ago certbot.timer  certbot.service

Pour tester le processus de renouvellement manuellement (sans apporter de modifications), exécutez:

sudo certbot renew --dry-run

Cela simule le processus de renouvellement complet et confirme que votre système est prêt à le gérer automatiquement.

S'il n'y a pas d'erreurs, vos certificats se renouvelleront tranquillement en arrière-plan à l'avenir.

Étapes finales et bonnes habitudes

Maintenant que votre proxy inversé est configuré et sécurisé avec SSL, c'est une bonne idée de conclure avec quelques contrôles pratiques et meilleures pratiques.

Ces habitudes simples peuvent aider à prévenir les problèmes en baisse, faciliter votre configuration à maintenir et à vous assurer que tout continue de fonctionner comme vous vous y attendez.

Même si tout semble fonctionner, passer quelques minutes supplémentaires ici peut vous faire gagner du temps et des problèmes plus tard.

Redémarrez votre application si elle ne détecte pas automatiquement les modifications
Certaines applications doivent être redémarrées pour fonctionner correctement derrière un proxy.

Vérifier les journaux
Vous pouvez surveiller les journaux Nginx pour les erreurs ou le trafic inhabituel:

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

Conservez Nginx et CERTBOT à jour
Utilisez régulièrement la mise à jour de Sudo Apt && sudo apt.Les packages mis à jour corrigent les bogues, améliorent la compatibilité et les problèmes de sécurité des correctifs.

Cas d'utilisation avancés pour le proxy inversé Nginx avec SSL

Une fois que vous avez maîtrisé les bases de la mise en place d'un proxy inversé sécurisé, vous pouvez étendre votre configuration pour répondre aux besoins plus complexes.Voici quelques scénarios courants qui peuvent vous aider à tirer le meilleur parti de votre serveur.

Hébergement de plusieurs applications sur un seul serveur

Si vous exécutez plusieurs applications Web sur différents ports, Nginx peut acheminer les demandes vers chaque application en fonction du domaine ou du chemin d'url.

Exemple: différents domaines

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

    location / {
        proxy_pass http://localhost:3001;
        # proxy headers here
    }
}

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

    location / {
        proxy_pass http://localhost:3002;
        # proxy headers here
    }
}

Cette configuration vous permet de servir plusieurs applications à l'aide de sous-domaines séparés, le tout via Nginx sur des ports standard.

Utiliser Docker?Apprendre comment proxy proxy plusieurs applications docker avec nginx.

Proxing basé sur le chemin

Alternativement, vous pouvez proxy basé sur des chemins d'urgence, ce qui est utile si vous voulez toutes les applications dans un seul domaine:

server {
    listen 80;
    server_name example.com;

    location /app1/ {
        proxy_pass http://localhost:3001/;
        # proxy headers here
    }

    location /app2/ {
        proxy_pass http://localhost:3002/;
        # proxy headers here
    }
}

Remarque: Lorsque vous utilisez la proxyation basée sur le chemin, les barres obliques et la réécriture d'URL peuvent devenir difficiles - assurez-vous que votre application backend peut gérer le service sous un sous-chemin.

Ajout de taux limitant pour protéger votre application

Vous pouvez limiter le nombre de demandes qu'un client peut faire dans un délai donné pour protéger votre backend contre les abus ou la surcharge accidentelle.

Ajoutez ceci dans le bloc HTTP dans /etc/nginx/nginx.conf:

limit_req_zone $binary_remote_addr zone=mylimit:10m rate=10r/s;

Ensuite, dans votre serveur ou votre bloc d'emplacement:

limit_req zone=mylimit burst=20 nodelay;

Cette configuration permet 10 demandes par seconde avec des éclats allant jusqu'à 20 demandes, supprimant les demandes excédentaires pour éviter écraser votre application.

Équilibrage des charges sur plusieurs serveurs backend

Si vous avez plusieurs instances de votre application en cours d'exécution (par exemple, plusieurs conteneurs ou VPSS), Nginx peut distribuer le trafic entre eux:

upstream backend {
    server 192.168.1.10:3000;
    server 192.168.1.11:3000;
}

server {
    listen 80;
    server_name example.com;

    location / {
        proxy_pass http://backend;
        # proxy headers here
    }
}

Nginx équilibre les rabats à la ronde par défaut, mais vous pouvez le configurer pour d'autres méthodes comme les moindres connexions ou le hachage IP.

Pour en savoir plus, consultez notre guide sur Équilibrage de chargement DNS.

Journalisation et débogage

Vous pouvez personnaliser la journalisation pour inclure des informations sur proxy importantes pour le dépannage ou l'analyse:

log_format proxy '$remote_addr - $remote_user [$time_local] '
                 '"$request" $status $body_bytes_sent '
                 '"$http_referer" "$http_user_agent" '
                 'upstream_response_time $upstream_response_time '
                 'request_time $request_time';

access_log /var/log/nginx/proxy_access.log proxy;

Cela enregistre les temps de réponse en amont et les temps de demande totaux, aidant à identifier les réponses backend lents.

En-têtes personnalisées et améliorations de sécurité

Vous voudrez peut-être ajouter ou modifier les en-têtes HTTP pour la sécurité ou les fonctionnalités:

add_header X-Frame-Options SAMEORIGIN;
add_header X-Content-Type-Options nosniff;
add_header Referrer-Policy no-referrer-when-downgrade;
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;

Ces en-têtes protègent contre le jacking, le reniflement de mime et applique l'utilisation des HTTPS.