Un laboratoire Nginx local vous offre un moyen sûr et rapide d'apprendre, de tester des modifications et de déboguer avant de toucher aux environnements partagés. En quelques minutes, vous pouvez déployer une instance Nginx isolée sous votre répertoire personnel, la faire tourner sur des ports non privilégiés et itérer sans risquer de corrompre la configuration système. Ce guide suit une approche pratique : inventorier l'existant, configurer un préfixe Nginx non privilégié, et implémenter trois petits exemples observables avec curl et les journaux : un site statique, un proxy inverse vers une application locale, et du HTTPS avec un certificat auto-signé. Vous verrez les résultats attendus, les pièges courants et un plan de retour arrière. Le résultat final est un flux de travail reproductible que vous pourrez recréer sur n'importe quelle station de travail. ## Inventaire des Versions et de l'Environnement Définissez votre périmètre et validez vos outils pour que le laboratoire se comporte de façon prévisible. Gardez le projet pilote étroit et mesurable : un seul hôte, des ports non privilégiés, et un unique répertoire appartenant à votre utilisateur. Prérequis : - Système d'exploitation : Linux ou macOS. Windows fonctionne via le zip officiel Nginx ou WSL ; les commandes ici supposent un shell de type Unix. - Outils installés : binaire nginx, curl, openssl, python3. - Ports locaux libres : 8080 pour HTTP, 8443 pour HTTPS, 3000 pour une application backend locale. - Accès au système de fichiers sous votre répertoire personnel. Confirmez les versions (sortie d'exemple) : nginx -v # nginx version: nginx/1.24.0 curl --version # curl 8.4.0 openssl version # OpenSSL 3.0.10 python3 --version # Python 3.11.x Installation (choisissez une méthode) : # Linux (Debian/Ubuntu) sudo apt-get update && sudo apt-get install -y nginx curl openssl python3 # Linux (RHEL/Fedora) sudo dnf install -y nginx curl openssl python3 # macOS (Homebrew) brew install nginx curl openssl python Si Nginx est déjà installé, vous pouvez réutiliser le binaire en toute sécurité tout en gardant votre laboratoire isolé en le pointant vers votre propre préfixe et vos propres fichiers de configuration. ## Chemin de Configuration Sûr Faites tourner Nginx sous votre utilisateur, liez-le à des ports élevés, et conservez tous les fichiers sous un unique répertoire de laboratoire. Cela évite de modifier /etc/nginx au niveau système et empêche les opérations privilégiées. Créez la structure du répertoire de laboratoire : export LAB="$HOME/nginx-lab" mkdir -p "$LAB/{conf,conf/sites,html,logs,certs} Créez une page d'index simple : cat > "$LAB/html/index.html" <<'EOF' Nginx Lab

Nginx Local Lab

It works.

EOF Écrivez la configuration de base Nginx à $LAB/conf/nginx.conf : worker_processes 1; error_log logs/error.log info; pid logs/nginx.pid; events { worker_connections 1024; } http { include mime.types; default_type application/octet-stream; log_format main '$remote_addr - $remote_user [$time_local] "$request" ' '$status $body_bytes_sent "$http_referer" ' '"$http_user_agent"'; access_log logs/access.log main; sendfile on; keepalive_timeout 65; include conf/sites/*.conf; } Cette configuration utilise $LAB/logs pour les journaux et inclut les configurations par site depuis $LAB/conf/sites . Elle ne touche jamais à /etc/nginx . Comment démarrer, arrêter et tester en utilisant votre préfixe : # Tester la syntaxe de la configuration nginx -p "$LAB" -t -c conf/nginx.conf # Démarrer nginx -p "$LAB" -c conf/nginx.conf # Recharger après modifications nginx -p "$LAB" -s reload # Arrêter nginx -p "$LAB" -s stop Astuce : Testez toujours ( -t ) avant de recharger. Nginx refuse de recharger une configuration invalide, ce qui constitue une garde-fou de sécurité dans votre laboratoire également. ## Exemples Pratiques Vous allez implémenter trois petits scénarios observables : un site statique, un proxy inverse basé sur le chemin vers une application locale, et du HTTPS sur un port élevé avec un certificat auto-signé. ## 1) Site Statique sur le Port 8080 Créez la configuration du site à $LAB/conf/sites/static.conf : server { listen 8080; server_name localhost; root html; index index.html; location /healthz { return 200 'ok\n'; add_header Content-Type text/plain; } location / { try_files $uri $uri/ =404; } error_page 404 /404.html; location = /404.html { internal; return 404 'not found\n'; add_header Content-Type text/plain; } } Comportement attendu : - http://127.0.0.1:8080/ sert votre index.html . - http://127.0.0.1:8080/healthz retourne le texte brut ok . ## 2) Proxy Inverse de /app/ vers un Backend Local sur le Port 3000 Démarrez un backend simple (dans un terminal séparé) : python3 -m http.server 3000 --bind 127.0.0.1 Créez la configuration du proxy à $LAB/conf/sites/reverse-proxy.conf : server { listen 8080; server_name localhost; # Limite de débit : 5 requêtes/seconde par IP client, rafale de 10 limit_req_zone $binary_remote_addr zone=api_limit:10m rate=5r/s; location /app/ { limit_req zone=api_limit burst=10 nodelay; proxy_set_header Host $host; proxy_set_header X-Forwarded-Proto $scheme; proxy_set_header X-Forwarded-For $remote_addr; proxy_http_version 1.1; proxy_pass http://127.0.0.1:3000/; } } Notes : - Le slash final dans location /app/ combiné avec proxy_pass .../3000/ mappe /app/foo vers /foo sur le backend. - La directive limit_req simule une limitation de débit style production dans le laboratoire. ## 3) HTTPS sur le Port 8443 avec un Certificat Auto-Signé Générez un certificat auto-signé : openssl req -x509 -nodes -days 365 -newkey rsa:2048 \ -keyout "$LAB/certs/selfsigned.key" \ -out "$LAB/certs/selfsigned.crt" \ -subj /C=US/ST=NA/L=Local/O=Lab/OU=Dev/CN=localhost Créez la configuration du serveur TLS à $LAB/conf/sites/tls.conf : server { listen 8443 ssl; server_name localhost; ssl_certificate certs/selfsigned.crt; ssl_certificate_key certs/selfsigned.key; ssl_protocols TLSv1.2 TLSv1.3; ssl_ciphers HIGH:!aNULL:!MD5; root html; index index.html; location / { try_files $uri $uri/ =404; } } Appliquez et testez l'ensemble : nginx -p "$LAB" -t -c conf/nginx.conf nginx -p "$LAB" -s reload À ce stade, vous avez : - Site statique HTTP sur 127.0.0.1:8080 - Proxy inverse basé sur le chemin sur 127.0.0.1:8080/app/ - Site statique HTTPS sur 127.0.0.1:8443 Inventaire du laboratoire :
ComposantPortChemin ou Notes
Préfixe Nginxn/a$HOME/nginx-lab
Site statique HTTP8080$LAB/conf/sites/static.conf, $LAB/html
Proxy inverse8080 (/app/)$LAB/conf/sites/reverse-proxy.conf → 127.0.0.1:3000
Site statique HTTPS8443$LAB/conf/sites/tls.conf, $LAB/certs
Application backend3000python3 -m http.server
## Vérification et Diagnostics Exécutez des vérifications simples et observables après chaque changement. Toutes les commandes ci-dessous ciblent localhost. Vérifiez le site statique : curl -i http://127.0.0.1:8080/ Exemple attendu (ligne de statut et quelques en-têtes) : HTTP/1.1 200 OK Server: nginx/1.24.0 Content-Type: text/html Content-Length: 123 Vérifiez l'endpoint de santé : curl -i http://127.0.0.1:8080/healthz Exemple attendu : HTTP/1.1 200 OK Content-Type: text/plain ok Vérifiez le mapping du proxy inverse : curl -i http://127.0.0.1:8080/app/ Exemple attendu (listing de répertoire depuis http.server de Python) : HTTP/1.1 200 OK Server: nginx/1.24.0 Directory listing for / Vérifiez HTTPS (auto-signé ; utilisez -k pour ignorer la confiance) : curl -k -i https://127.0.0.1:8443/ Exemple attendu : HTTP/1.1 200 OK Server: nginx/1.24.0 Content-Type: text/html Consultez les journaux pendant les tests : tail -f "$LAB/logs/access.log" "$LAB/logs/error.log" Confirmez les écouteurs : # Linux ss -lntp | grep -E ':8080|:8443' # macOS lsof -iTCP -sTCP:LISTEN -n | egrep ':8080|:8443' Exemple attendu montre nginx en écoute sur 127.0.0.1:8080 et 0.0.0.0:8443 (ou similaire, selon votre config). Validez la syntaxe de la configuration avant de recharger : nginx -p "$LAB" -t -c conf/nginx.conf Exemple attendu : nginx: the configuration file conf/nginx.conf syntax is ok nginx: configuration file conf/nginx.conf test is successful Si une vérification échoue, cherchez l'erreur précise dans $LAB/logs/error.log , puis relancez -t pour attraper les erreurs de syntaxe tôt. ## Modes de Défaillance et Récupération Anticipez les problèmes courants et gardez le retour arrière trivial en versionnant ou copiant les fichiers connus bons. Patron de retour arrière rapide : # Avant de grosses modifications, capturez vos configs cp -a "$LAB/conf" "$LAB/conf.good.$(date +%s)" # En cas d'échec, restaurez et rechargez rsync -a --delete "$LAB/conf.good.TIMESTAMP/" "$LAB/conf/" && \ nginx -p "$LAB" -t -c conf/nginx.conf && \ nginx -p "$LAB" -s reload Problèmes courants et correctifs :
SymptômeCause ProbableCorrectif Rapide
nginx -t échoue avec ligne:colErreur de syntaxe (point-virgule manquant, directive invalide)Ouvrez le fichier signalé par nginx -t, corrigez la ligne, testez à nouveau
curl vers :8080 donne connection refusedNginx non démarré ou écoute sur une autre IPVérifiez ss/lsof, démarrez avec nginx -p "$LAB" -c conf/nginx.conf
curl vers :8080/app/ retourne 404Mismatch de chemin du proxyAssurez-vous que location /app/ et proxy_pass http://127.0.0.1:3000/ (notez le slash final)
502 Bad Gateway sur /app/Backend non démarréLancez python3 -m http.server 3000 et réessayez
403 Forbidden sur fichiers statiquesMauvais root ou permissions fichiersroot html; assurez-vous que les fichiers existent et sont lisibles par votre utilisateur
Échec handshake TLS ou avertissement navigateurCertificat auto-signé non approuvéUtilisez curl -k pour les tests ; pour navigateurs, importez ou acceptez pour le labo uniquement
Port déjà utiliséUn autre processus a lié 8080/8443Changez les ports d'écoute ou arrêtez l'autre processus
En cas de doute, augmentez temporairement la verbosité : # Dans nginx.conf (bloc http), temporairement : error_log logs/error.log debug; Puis reproduisez la requête qui échoue, inspectez error.log , et remettez le niveau de log ensuite pour éviter les journaux bruyants. ## Liste de Contrôle Opérationnelle Utilisez cette procédure courte et reproductible pour déployer et valider votre laboratoire Nginx local. Tous les chemins sont sous $HOME/nginx-lab . Configuration : - Assurez-vous que nginx , curl , openssl , python3 sont installés et dans le PATH. - mkdir -p $LAB/{conf,conf/sites,html,logs,certs} - Créez $LAB/conf/nginx.conf comme montré. - Créez $LAB/conf/sites/static.conf et reverse-proxy.conf comme montré. - Écrivez index.html dans $LAB/html . - Générez les certificats auto-signés dans $LAB/certs . Démarrage : - Démarrez le backend : python3 -m http.server 3000 --bind 127.0.0.1 - nginx -p "$LAB" -t -c conf/nginx.conf - nginx -p "$LAB" -c conf/nginx.conf Vérification : - curl -i http://127.0.0.1:8080/ - curl -i http://127.0.0.1:8080/healthz - curl -i http://127.0.0.1:8080/app/ - curl -k -i https://127.0.0.1:8443/ - tail -f $LAB/logs/access.log $LAB/logs/error.log (si besoin) Itérez en toute sécurité : - Modifiez un fichier de site sous conf/sites . - nginx -p "$LAB" -t -c conf/nginx.conf - nginx -p "$LAB" -s reload - Relancez les curl ciblés. Arrêt et nettoyage : - nginx -p "$LAB" -s stop - pkill -f "python3 -m http.server 3000" (ou Ctrl+C dans son terminal) Extensions optionnelles (pour plus tard) : - Ajoutez des en-têtes gzip et de mise en cache au contenu statique. - Introduisez un second upstream et testez proxy_next_upstream et les vérifications de santé. - Créez un bloc serveur distinct pour l'API sur un port dédié, puis testez CORS (Cross-Origin Resource Sharing : mécanisme permettant aux ressources web d'être demandées depuis un domaine différent). Gardez chaque extension petite et vérifiable. ## Conclusion Vous disposez maintenant d'un laboratoire Nginx sûr et non privilégié qui sert du contenu statique, fait du proxy vers un backend local, et termine le TLS (Transport Layer Security : protocole cryptographique assurant la confidentialité et l'intégrité des communications) avec un certificat auto-signé. La structure garde tous les fichiers sous un préfixe unique, utilise des ports non privilégiés, et s'appuie sur nginx -t ainsi que les journaux d'accès et d'erreur pour un retour rapide. Comme prochaines étapes, étendez une capacité à la fois : ajoutez des en-têtes de mise en cache, expérimentez avec les limites de débit, ou pratiquez les échanges de configuration bleu/vert en conservant deux fichiers de site et en basculant les inclusions. Gardez les changements petits, vérifiez avec curl, et privilégiez le rechargement au redémarrage. Cela rend votre apprentissage reproductible, observable et à faible risque.