Comment configurer un proxy inverse Nginx sur Ubuntu

Un proxy inverse Nginx reçoit les requêtes des visiteurs d’un site web et les transmet à un autre serveur ou à une autre application. Il est couramment utilisé pour rendre les applications fonctionnant sur des ports tels que le port 3000 accessibles via un nom de domaine, sans exposer leurs ports internes à Internet.

Dans ce tutoriel, vous allez configurer Nginx sur Ubuntu pour transmettre les requêtes à une application locale, associer un domaine et activer HTTPS.

Qu’est-ce qu’un proxy inverse Nginx ?

Un proxy inverse se place entre les visiteurs et votre application backend.

Au lieu de se connecter directement à une application fonctionnant sur le port 3000, les visiteurs se connectent à Nginx sur les ports HTTP ou HTTPS standard.

Nginx transmet la requête à l’application et renvoie sa réponse.

Le parcours d’une requête est le suivant :

Visiteur → Nginx → Application backend

Cette configuration est couramment utilisée pour Node.js, Python et d’autres applications web. Elle peut également prendre en charge la terminaison TLS, la répartition de charge et la gestion centralisée des requêtes.

Prérequis

Avant de commencer, vous aurez besoin des éléments suivants :

• Un serveur Ubuntu 24.04 LTS avec un accès sudo.
• Un accès SSH à votre serveur.
• Un nom de domaine pointant vers l’adresse IP publique de votre serveur.
• Une application backend à l’écoute sur un port local.

Dans cet exemple, nous utiliserons le port 3000.

Si vous débutez avec SSH, consultez notre guide des commandes SSH pour débutants avant de poursuivre.

Étape 1 : installer Nginx sur Ubuntu

Connectez-vous à votre serveur Ubuntu via SSH.

Mettez à jour l’index des paquets et installez Nginx :

sudo apt update
sudo apt install nginx -y

Vérifiez que Nginx est en cours d’exécution :

sudo systemctl status nginx

Vous devriez voir active (running).

Si Nginx n’a pas démarré, exécutez :

sudo systemctl enable --now nginx

Vous pouvez également saisir l’adresse IP publique de votre serveur dans un navigateur. La page d’accueil par défaut de Nginx devrait s’afficher si l’accès HTTP est autorisé.

Si vous utilisez UFW, autorisez le trafic HTTP et HTTPS :

sudo ufw allow 'Nginx Full'

Vérifiez également les règles de pare-feu configurées auprès de votre fournisseur d’hébergement. Ne désactivez pas le pare-feu pour rendre Nginx accessible.

Étape 2 : démarrer une application backend de test

Avant de configurer le proxy inverse, il nous faut une application vers laquelle Nginx transmettra les requêtes.

Pour effectuer un test simple, créez un répertoire temporaire :

mkdir -p ~/nginx-proxy-test
cd ~/nginx-proxy-test

Créez une page HTML simple :

echo '<h1>Nginx Reverse Proxy Works!</h1>' > index.html

Démarrez maintenant le serveur HTTP intégré à Python :

python3 -m http.server 3000 --bind 127.0.0.1

Il sert votre page de test sur le port 3000, accessible uniquement via l’adresse de bouclage locale.

Laissez ce terminal ouvert et ouvrez une deuxième session SSH.

Vérifiez que l’application répond :

curl http://127.0.0.1:3000

Vous devriez voir :

<h1>Nginx Reverse Proxy Works!</h1>

Ce serveur Python sert uniquement à la démonstration. Pour une application en production, utilisez le serveur d’application recommandé et la configuration de gestion des services appropriée.

Étape 3 : créer une configuration de proxy inverse Nginx

Créez un nouveau bloc serveur Nginx :

sudo nano /etc/nginx/sites-available/app.example.com

Remplacez app.example.com par votre domaine.

Ajoutez la configuration suivante :

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

Enregistrez le fichier.

Comprendre la configuration

• listen 80 accepte les requêtes HTTP.
• server_name indique le domaine que Nginx doit gérer.
• proxy_pass transmet les requêtes à l’application sur le port 3000.
• proxy_set_header transmet à l’application backend des informations utiles sur la requête d’origine.

L’application backend doit comprendre et traiter de manière sécurisée les en-têtes transmis. Ne configurez les applications pour qu’elles fassent confiance à ces en-têtes que lorsque les requêtes arrivent par votre proxy de confiance.

Étape 4 : activer et tester la configuration

Activez votre nouveau bloc serveur :

sudo ln -s /etc/nginx/sites-available/app.example.com /etc/nginx/sites-enabled/

Si le lien existe déjà, ne le recréez pas.

Vérifiez que la configuration ne comporte pas d’erreurs :

sudo nginx -t

Si le test réussit, rechargez Nginx :

sudo systemctl reload nginx

Ouvrez maintenant :

http://app.example.com

Si le DNS pointe vers le bon serveur et que l’application backend de test fonctionne toujours, vous devriez voir :

Nginx Reverse Proxy Works!

Si la page par défaut de Nginx s’affiche à la place, vérifiez les enregistrements DNS de votre domaine et la configuration de server_name.

Étape 5 : activer HTTPS avec Let’s Encrypt

Pour un site web public, utilisez HTTPS plutôt que de laisser le trafic non chiffré.

Vérifiez d’abord que votre domaine pointe vers le bon serveur et que le port 80 est accessible depuis l’extérieur. Ces conditions sont importantes pour la procédure standard de validation du certificat par HTTP.

Installez Certbot en suivant la méthode officielle basée sur Snap :

sudo snap install --classic certbot

Si la commande certbot n’est pas encore disponible, créez le lien vers la commande :

sudo ln -s /snap/bin/certbot /usr/local/bin/certbot

Demandez ensuite un certificat :

sudo certbot --nginx -d app.example.com

Suivez les instructions affichées. Certbot peut obtenir un certificat et configurer Nginx pour rendre votre domaine accessible en HTTPS.

Testez ensuite le renouvellement du certificat :

sudo certbot renew --dry-run

Rendez-vous sur :

https://app.example.com

Votre application de test devrait maintenant se charger via une connexion chiffrée.

Étape 6 : vérifier votre proxy inverse

Vérifiez la réponse HTTPS :

curl -I https://app.example.com

Pour l’application backend Python de l’exemple, une réponse HTTP 200 OK indique que la requête est bien parvenue à l’application.

Vous pouvez également vérifier quels processus sont à l’écoute sur votre serveur :

sudo ss -ltnp

Votre installation Nginx devrait être à l’écoute sur les ports HTTP et HTTPS publics configurés, tandis que l’application backend de l’exemple est à l’écoute sur 127.0.0.1:3000.

N’oubliez pas que le serveur Python temporaire s’arrêtera lorsque vous fermerez sa session de terminal. Les applications en production doivent fonctionner sous la supervision d’un gestionnaire de processus tel que systemd.

Problèmes courants avec un proxy inverse Nginx

502 Bad Gateway

Cela signifie généralement que Nginx n’a pas pu recevoir de réponse valide de l’application backend.

Vérifiez que votre application fonctionne et que le port indiqué dans proxy_pass est correct.

504 Gateway Timeout

Une erreur 504 se produit lorsque la passerelle ne reçoit pas à temps la réponse attendue du serveur en amont.

Examinez les requêtes lentes et les performances de l’application backend avant d’augmenter les délais d’attente.

Le domaine ne se charge pas

Vérifiez que l’enregistrement A de votre domaine pointe vers la bonne adresse IP publique, que les ports concernés sont ouverts dans le pare-feu et que le bloc serveur Nginx correspond au nom d’hôte demandé.

Questions fréquentes

Conclusion

Vous avez configuré un proxy inverse Nginx sur Ubuntu, transmis les requêtes à une application locale et activé HTTPS.

Vous pouvez adapter cette configuration de base à Node.js, Python et à d’autres applications utilisant HTTP en modifiant l’adresse de l’application backend dans proxy_pass.

Avant d’utiliser cette configuration en production, assurez-vous que votre application démarre automatiquement, fonctionne avec les permissions appropriées et dispose d’une surveillance et de mesures de sécurité adéquates.