Comment configurer un reverse proxy Nginx sur un VPS Linux

Un reverse proxy Nginx agit comme intermédiaire entre vos visiteurs et vos applications backend, offrant filtrage, cache, terminaison SSL et répartition de charge. Ce tutoriel détaille l'installation, la configuration et la sécurisation d'un reverse proxy Nginx sur un serveur Linux, avec des exemples concrets adaptés aux infrastructures de production hébergées sur VPS Linux OmegaCloud. Un VPS Nextcloud se place typiquement derrière ce type de proxy, qui assure la terminaison TLS.

Pourquoi utiliser un reverse proxy Nginx ?

Nginx excelle dans le rôle de reverse proxy grâce à son architecture événementielle et sa consommation mémoire réduite. Contrairement à Apache en mode préfork, Nginx gère des milliers de connexions simultanées sans générer un processus par requête. Cette efficacité en fait le choix privilégié pour exposer des applications Node.js, Python (Gunicorn/uWSGI), PHP-FPM ou Java (Tomcat) vers Internet.

Les cas d'usage typiques incluent :

• Terminaison TLS/SSL : Nginx chiffre le trafic HTTPS tandis que le backend communique en HTTP local, simplifiant la gestion des certificats.
• Cache HTTP : stockage en RAM ou SSD des réponses statiques pour réduire la charge backend.
• Load balancing : distribution round-robin, least_conn ou ip_hash entre plusieurs serveurs applicatifs.
• Sécurité périmétrique : filtrage des headers, limitation de débit (limit_req), blocage d'IP malveillantes avant qu'elles n'atteignent l'application.

Sur un OmegaCloud VPS SSD SAS avec uplink redondant, cette architecture permet de servir plusieurs milliers de requêtes par seconde tout en maintenant une latence sub-milliseconde entre le proxy et les backends hébergés sur le même datacenter.

Installation et configuration initiale du reverse proxy Nginx

Installation sur Debian/Ubuntu

Connectez-vous en SSH root sur votre VPS et installez Nginx depuis les dépôts officiels :

apt update
apt install nginx -y
systemctl enable nginx
systemctl start nginx

Vérifiez le statut du service :

systemctl status nginx

Pour Rocky Linux ou AlmaLinux (dérivés RHEL), utilisez DNF :

dnf install nginx -y
systemctl enable --now nginx
firewall-cmd --permanent --add-service=http
firewall-cmd --permanent --add-service=https
firewall-cmd --reload

Structure des fichiers de configuration

La configuration Nginx s'organise ainsi :

• /etc/nginx/nginx.conf : fichier principal définissant worker_processes, events, http block.
• /etc/nginx/sites-available/ : virtual hosts (Debian/Ubuntu).
• /etc/nginx/sites-enabled/ : symlinks actifs.
• /etc/nginx/conf.d/ : inclusions automatiques (RHEL/Rocky).

Testez la syntaxe après chaque modification :

nginx -t

Rechargez sans interruption de service :

systemctl reload nginx

Premier reverse proxy vers une application Node.js

Supposons une application Express écoutant sur localhost:3000. Créez /etc/nginx/sites-available/app.example.com :

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

    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_cache_bypass $http_upgrade;
    }
}

Activez le site :

ln -s /etc/nginx/sites-available/app.example.com /etc/nginx/sites-enabled/
nginx -t
systemctl reload nginx

Les headers X-Real-IP et X-Forwarded-For transmettent l'adresse IP du client réel à l'application backend, indispensable pour les logs et la géolocalisation. Le header X-Forwarded-Proto indique le schéma (http/https) de la requête originale, utile pour que l'application génère des URLs absolues cohérentes.

Sécurisation et optimisations avancées

Terminaison SSL/TLS avec Let's Encrypt

Installez Certbot pour automatiser l'émission et le renouvellement des certificats :

apt install certbot python3-certbot-nginx -y
certbot --nginx -d app.example.com

Certbot modifie automatiquement votre virtual host pour écouter sur le port 443 et rediriger HTTP vers HTTPS. Le renouvellement s'effectue via un timer systemd vérifié avec :

systemctl list-timers | grep certbot

Pour renforcer la sécurité TLS, ajoutez dans le bloc server HTTPS :

ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers 'ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256';
ssl_prefer_server_ciphers off;
ssl_session_cache shared:SSL:10m;
ssl_session_timeout 10m;
ssl_stapling on;
ssl_stapling_verify on;
resolver 1.1.1.1 1.0.0.1 valid=300s;
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;

Ces directives activent le stapling OCSP (réduction de la latence lors du handshake TLS) et forcent HSTS pour empêcher le downgrade vers HTTP. La directive ssl_prefer_server_ciphers off privilégie les choix du client moderne, améliorant la compatibilité avec les navigateurs récents selon les recommandations de Mozilla Server Side TLS.

Limitation de débit et protection DDoS applicative

L'anti-DDoS volumétrique est géré automatiquement au niveau kernel par l'infrastructure VPS Linux OmegaCloud. Pour protéger l'application contre les abus applicatifs (Layer 7), configurez limit_req_zone dans le bloc http de /etc/nginx/nginx.conf :

http {
    limit_req_zone $binary_remote_addr zone=one:10m rate=10r/s;
    limit_req_status 429;
    ...
}

Puis dans le virtual host :

location / {
    limit_req zone=one burst=20 nodelay;
    proxy_pass http://127.0.0.1:3000;
    ...
}

Cette configuration autorise 10 requêtes par seconde par IP, avec un burst de 20 requêtes instantanées avant rejet (HTTP 429). Le paramètre nodelay empêche la mise en file d'attente, refusant immédiatement les requêtes excédentaires.

Mise en cache HTTP des réponses statiques

Activez le cache Nginx pour réduire la charge backend :

http {
    proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=app_cache:10m max_size=1g inactive=60m use_temp_path=off;
    ...
}

Dans le virtual host :

location / {
    proxy_cache app_cache;
    proxy_cache_valid 200 60m;
    proxy_cache_valid 404 10m;
    proxy_cache_use_stale error timeout updating http_500 http_502 http_503 http_504;
    proxy_cache_background_update on;
    proxy_cache_lock on;
    add_header X-Cache-Status $upstream_cache_status;
    proxy_pass http://127.0.0.1:3000;
    ...
}

Le header X-Cache-Status retourne HIT, MISS, BYPASS ou STALE pour déboguer le comportement du cache. La directive proxy_cache_use_stale sert du contenu expiré si le backend est indisponible, garantissant une haute disponibilité. Sur un VPS SSD SAS, le cache disque atteint des latences inférieures à 100 µs, rendant cette approche très performante.

Load balancing entre plusieurs backends

Définissez un groupe upstream dans /etc/nginx/nginx.conf ou un fichier inclus :

http {
    upstream backend_cluster {
        least_conn;
        server 127.0.0.1:3001 max_fails=3 fail_timeout=30s;
        server 127.0.0.1:3002 max_fails=3 fail_timeout=30s;
        server 127.0.0.1:3003 backup;
    }
    ...
}

Utilisez cet upstream dans le virtual host :

location / {
    proxy_pass http://backend_cluster;
    ...
}

L'algorithme least_conn envoie les nouvelles requêtes au serveur ayant le moins de connexions actives. Le paramètre backup désigne un serveur sollicité uniquement si les primaires sont indisponibles. Pour une répartition sticky (même client → même backend), utilisez ip_hash au lieu de least_conn.

Intégration avec les outils OmegaCloud et monitoring

Gestion DNS et provisioning automatique

Le panel OmegaCloud permet de gérer les zones DNS depuis le dashboard temps réel. Créez un enregistrement A pointant app.example.com vers l'IPv4 publique de votre VPS. Pour automatiser le déploiement de virtual hosts Nginx via l'API OmegaCloud, utilisez un script shell appelé depuis un pipeline CI/CD :

#!/bin/bash
API_KEY="votre_cle_api"
DOMAIN="app.example.com"
VPS_IP="203.0.113.42"

# Créer enregistrement DNS via API
curl -X POST https://api.omega-cloud.fr/v1/dns/zones/example.com/records \
  -H "Authorization: Bearer $API_KEY" \
  -d '{"type":"A","name":"app","content":"'$VPS_IP'","ttl":300}'

# Déployer configuration Nginx
ssh root@$VPS_IP "cat > /etc/nginx/sites-available/$DOMAIN <

Ce pattern s'intègre dans GitHub Actions ou GitLab CI pour un provisioning déclaratif de votre infrastructure reverse proxy.

Monitoring temps réel avec le dashboard OmegaCloud

Le panel OmegaCloud affiche CPU, RAM, I/O disque et trafic réseau en temps réel. Complétez ce monitoring système par des métriques applicatives en exposant le stub_status Nginx :

server {
    listen 127.0.0.1:8080;
    location /nginx_status {
        stub_status;
        access_log off;
    }
}

Interrogez ensuite localement :

curl http://127.0.0.1:8080/nginx_status

Pour collecter ces métriques, utilisez node_exporter (Prometheus) ou Telegraf (InfluxDB), installables via des packages Debian/Ubuntu. Les snapshots du panel OmegaCloud permettent de capturer l'état du VPS avant toute modification de configuration critique, facilitant le rollback en cas d'incident.

Sécurisation SSH et firewall système

Un reverse proxy Nginx exposé sur Internet nécessite un durcissement du système d'exploitation. Désactivez l'authentification par mot de passe SSH en éditant /etc/ssh/sshd_config :

PasswordAuthentication no
PermitRootLogin prohibit-password
PubkeyAuthentication yes

Rechargez le service SSH :

systemctl reload sshd

Configurez UFW pour autoriser uniquement HTTP, HTTPS et SSH :

ufw default deny incoming
ufw default allow outgoing
ufw allow 22/tcp
ufw allow 80/tcp
ufw allow 443/tcp
ufw enable

Installez fail2ban pour bannir automatiquement les IP tentant un bruteforce SSH :

apt install fail2ban -y
systemctl enable fail2ban

Créez /etc/fail2ban/jail.local :

[sshd]
enabled = true
port = 22
maxretry = 3
bantime = 3600

Rechargez fail2ban :

systemctl reload fail2ban

L'anti-DDoS inclus par défaut sur les VPS OmegaCloud filtre les attaques volumétriques (SYN flood, UDP amplification) au niveau du datacenter, garantissant que votre reverse proxy Nginx ne subisse que du trafic légitime ou des abus applicatifs gérables par limit_req.

Conclusion

La configuration d'un reverse proxy Nginx sur un VPS Linux requiert rigueur et connaissance des directives proxy_pass, proxy_set_header, ainsi que des mécanismes de cache et de load balancing. En exploitant les performances SSD SAS et l'uplink redondant d'un VPS Linux OmegaCloud, vous obtenez une architecture de production capable de gérer des milliers de requêtes par seconde tout en conservant une latence minimale et une sécurité renforcée.

FAQ

Comment transmettre l'IP réelle du client à mon application backend derrière Nginx ?

Utilisez les directives proxy_set_header X-Real-IP $remote_addr; et proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; dans le bloc location. Votre application devra lire ces headers HTTP pour récupérer l'IP d'origine au lieu de voir 127.0.0.1.

Peut-on utiliser Nginx comme reverse proxy pour des applications WebSocket ?

Oui, ajoutez proxy_http_version 1.1;, proxy_set_header Upgrade $http_upgrade; et proxy_set_header Connection 'upgrade'; dans le bloc location. Ces directives permettent à Nginx de maintenir la connexion persistante requise par le protocole WebSocket.

Comment renouveler automatiquement les certificats Let's Encrypt avec Nginx ?

Certbot installe un timer systemd (certbot.timer) qui tente le renouvellement deux fois par jour. Vérifiez son activation avec systemctl list-timers | grep certbot. Certbot exécute automatiquement nginx -s reload après un renouvellement réussi grâce au plugin python3-certbot-nginx.