Configurer Nginx en reverse proxy

Un reverse proxy place Nginx devant votre application : les visiteurs parlent à Nginx sur le port 80 ou 443, et Nginx transmet la requête à un processus qui écoute en local. L'application n'est plus exposée directement, les certificats et les journaux sont centralisés, et vous pouvez changer de port interne sans toucher au DNS. C'est la configuration standard pour Node.js, Python, Go ou Java.

Préparer l'application

L'application doit écouter sur la boucle locale, par exemple 127.0.0.1:3000, et non sur 0.0.0.0. Vérifiez avant de configurer Nginx :

curl -I http://127.0.0.1:3000
sudo ss -tlnp 'sport = :3000'

Si l'application n'écoute que sur 127.0.0.1, elle n'est pas joignable depuis Internet : c'est voulu. Le nom de domaine doit déjà pointer vers le VPS avec un enregistrement A ou AAAA avant de tester sérieusement le proxy.

Créer le bloc serveur

Créez /etc/nginx/sites-available/app.votre-domaine.fr :

server {
    listen 80;
    listen [::]:80;
    server_name app.votre-domaine.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;
    }
}

Activez-le :

sudo ln -s /etc/nginx/sites-available/app.votre-domaine.fr /etc/nginx/sites-enabled/
sudo nginx -t
sudo systemctl reload nginx

Host conserve le nom demandé, ce que l'application utilise pour générer des URL. X-Real-IP et X-Forwarded-For transmettent l'adresse du client pour les journaux et les limitations de débit. X-Forwarded-Proto indique le schéma d'origine, utile quand TLS est terminé par Nginx.

WebSocket, délais et taille

Pour une application qui utilise WebSocket, ajoutez une table map dans le contexte http, par exemple dans /etc/nginx/conf.d/upgrade.conf :

map $http_upgrade $connection_upgrade {
    default upgrade;
    ''      close;
}

Puis, dans le bloc location :

proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection $connection_upgrade;
proxy_read_timeout 3600s;

Sans ces en-têtes, la poignée de main WebSocket échoue et la connexion retombe en polling ou se ferme. proxy_read_timeout vaut 60 secondes par défaut : une connexion inactive plus longtemps est coupée. Pour le streaming ou les longues requêtes, augmentez-le et envisagez proxy_buffering off;.

Pour les téléversements, client_max_body_size 10m; évite un 413 Request Entity Too Large. Placez-le dans le bloc server ou location.

Tester et diagnostiquer

sudo nginx -t
sudo systemctl reload nginx
curl -I -H 'Host: app.votre-domaine.fr' http://127.0.0.1
curl -I https://app.votre-domaine.fr

• 502 Bad Gateway : l'application ne tourne pas, écoute sur un autre port ou sur une autre interface.
• 504 Gateway Timeout : l'application dépasse proxy_read_timeout.
• 413 : corps de requête trop volumineux.
• 404 : mauvais location ou mauvaise racine, pas un problème de proxy.

Consultez /var/log/nginx/error.log : Nginx y indique le port contacté et l'erreur exacte. Vérifiez aussi que l'application lit correctement les en-têtes X-Forwarded-* et ne fait pas confiance aveuglément à X-Forwarded-For venant d'Internet.

• Gardez l'application sur 127.0.0.1 et n'ouvrez son port dans aucun pare-feu.
• Terminez TLS avec Certbot sur Nginx, puis redirigez HTTP vers HTTPS.
• Ajoutez une route de santé et surveillez les codes 5xx.
• Après chaque modification : nginx -t, rechargement, puis test réel.

Vérifier

sudo nginx -T | grep -A5 'server_name app.votre-domaine.fr'
curl -s -o /dev/null -w '%{http_code}\n' https://app.votre-domaine.fr

Le code doit être 200, 301 ou 302, jamais 502. Si vous avez changé de port interne, confirmez avec ss -tlnp que l'application écoute encore et que proxy_pass pointe vers le bon port.