Si vous auto-hébergez plusieurs services web — un blog, un tableau de bord de surveillance, un serveur de fichiers — vous êtes rapidement confronté à un problème : chaque service veut les ports 80 et 443. Un proxy inverse résout ce problème en se plaçant devant tous vos services et en routant les requêtes en fonction des noms de domaine.

Architecture

L’idée est simple :

Client → tuxvador.fr:443 → NGINX Proxy Inverse
                            ├── /blog → dev-srv:5000
                            ├── /grafana → mon-srv:8889
                            └── /api → dev-srv:3001

Le proxy inverse est le seul conteneur exposé à internet (via la redirection de ports sur votre routeur). Tous les autres services sont internes, inaccessibles depuis l’extérieur et n’ont pas d’adresse IP publique.

Installation de NGINX

Sur Debian 13 :

apt update && apt install -y nginx certbot python3-certbot-nginx

Configuration d’un proxy de base

Voici un bloc serveur minimal pour servir de proxy vers un blog tournant sur le port 5000 :

server {
    listen 80;
    server_name tuxvador.fr;

    location / {
        proxy_pass http://10.99.99.20:5000;
        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;
    }
}

Les directives clés :

• proxy_pass — où transférer les requêtes. Utilisez des adresses IP internes, pas publiques.
• proxy_set_header — transmettez les informations du client d’origine pour que le serveur backend voie les vraies adresses IP.
• server_name — quel domaine ce bloc gère.

Ajout de TLS avec Certbot

Une fois que votre domaine pointe vers l’adresse IP publique du proxy :

certbot --nginx -d tuxvador.fr -d www.tuxvador.fr

Certbot modifie automatiquement votre configuration NGINX pour servir en HTTPS, configure les redirections et met en place le renouvellement automatique via une minuterie systemd.

Configuration multiservice avec différents domaines

Si vous avez plusieurs domaines pointant vers la même adresse IP :

# Blog
server {
    listen 443 ssl;
    server_name tuxvador.fr;
    ssl_certificate /etc/letsencrypt/live/tuxvador.fr/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/tuxvador.fr/privkey.pem;

    location / {
        proxy_pass http://10.99.99.20:5000;
        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;
    }
}

# Grafana
server {
    listen 443 ssl;
    server_name monitoring.tuxvador.fr;
    ssl_certificate /etc/letsencrypt/live/monitoring.tuxvador.fr/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/monitoring.tuxvador.fr/privkey.pem;

    location / {
        proxy_pass http://10.99.99.10:8889;
        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;
    }
}

Sous-chemin ou sous-domaine

Vous avez deux options pour le routage :

• Sous-domaine : blog.tuxvador.fr → app A, monitoring.tuxvador.fr → app B
• Sous-chemin : tuxvador.fr/blog → app A, tuxvador.fr/monitoring → app B

Les sous-domaines sont plus propres pour les applications qui s’attendent à être à la racine. Les sous-chemins nécessitent que l’application backend supporte le routage basé sur le chemin (ou que vous réécriviez les chemins). J’utilise des sous-domaines pour les services de production.

En-têtes de sécurité

Ajoutez ces en-têtes à chaque bloc serveur HTTPS :

add_header X-Frame-Options "SAMEORIGIN" always;
add_header X-Content-Type-Options "nosniff" always;
add_header X-XSS-Protection "1; mode=block" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;

Vérifier votre configuration

nginx -t                    # tester la config
systemctl reload nginx      # appliquer les modifications
certbot renew --dry-run     # vérifier que le renouvellement fonctionne

Pièges courants

WebSockets : Les applications comme Jupyter ou VS Code Server ont besoin du support WebSocket. Ajoutez au bloc location :

proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";

Fichiers volumineux : Par défaut, NGINX limite la taille du corps des requêtes à 1 Mo. Augmentez-la avec :

client_max_body_size 100M;

Journalisation : NGINX enregistre tout dans /var/log/nginx/. Surveillez ces fichiers pour détecter des requêtes inhabituelles — ce sont les premiers signes de scanners sondant vos services.