Générateur de configuration Nginx

Générer la configuration Nginx

Écrire des configurations Nginx à partir de zéro signifie se souvenir de chaque proxy_set_header, de chaque type MIME gzip, et de la différence entre try_files $uri/ /index.php?$args et la version qui casse subtilement le routage. Ce générateur demande le domaine, l’upstream, le gestionnaire PHP et les chemins SSL, puis génère un bloc de serveur avec des valeurs par défaut sensées pour TLS, HTTP/2, mise en cache statique et compression.

Comment générer votre bloc de serveur

  1. 1

    Choisissez un préréglage

    Site statique, PHP-FPM (Laravel, WordPress), proxy inverse Node.js, ou une simple redirection 301.

  2. 2

    Entrez le domaine

    Incluez la liste des server_name: généralement les variantes www et non-www.

  3. 3

    Définir les détails SSL

    Indiquez vos fichiers fullchain et privkey, ou passez pour utiliser uniquement HTTP.

  4. 4

    Ajuster l'upstream

    Port, chemin de socket, ou URL backend pour les cas de proxy_pass.

  5. 5

    Copier et déployer

    Déposez la sortie dans /etc/nginx/sites-available, exécutez nginx -t et rechargez.

À quoi ressemble un bon bloc de serveur

Un hôte virtuel Nginx moderne a généralement ces éléments :

Section But
listen 443 ssl http2 Accepter HTTPS avec HTTP/2 activé
ssl_certificate + ssl_certificate_key Pointer vers le matériel TLS
ssl_protocols TLSv1.2 TLSv1.3 Supprimer les anciennes versions de TLS
gzip on + types Compresser le texte/HTML/JSON/JS/CSS à la volée
En-têtes expires pour les fichiers statiques Réduire les allers-retours des visiteurs récurrents
try_files Router vers un contrôleur frontal (PHP, Laravel, etc.)
HSTS + en-têtes de sécurité Garder le navigateur honnête sur TLS

Essentiels du proxy inverse

Pour les applications Node.js, Python, Ruby fonctionnant derrière Nginx :

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;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
}

Oublier X-Forwarded-For est la manière classique de perdre les vraies adresses IP des clients dans vos journaux d’application.

Erreurs courantes

  • Absence de repli server_name. Nginx utilise le premier bloc de serveur par défaut si aucun nom ne correspond. Mettez un bloc server_name _ qui retourne 444 pour éviter les attaques par en-tête d’hôte.
  • Ordre de certificat incorrect. Le fichier ssl_certificate doit être fullchain (feuille + intermédiaires), pas seulement la feuille.
  • Mise en cache trop enthousiaste. Envoyer expires 1y sur /index.html ruinera les déploiements. Versionnez plutôt les URL des actifs.
  • Pas de test avant le rechargement. Exécutez toujours nginx -t avant systemctl reload nginx: une erreur de syntaxe met le site hors ligne.

Questions fréquentes

HTTP/2 est stable et universellement supporté dans Nginx 1.25+. HTTP/3 (QUIC) est disponible dans Nginx 1.25+ en tant qu’expérimental. Pour une configuration de production en 2025, activez HTTP/2 et éventuellement superposez HTTP/3 avec les directives http3 et quic.

La convention est /etc/ssl/certs/ pour les chaînes publiques et /etc/ssl/private/ pour les clés. Let’s Encrypt place tout sous /etc/letsencrypt/live/domain/. Utilisez celui que votre outil de renouvellement attend.

Oui, pour la plupart des sites. Ajoutez un bloc de serveur séparé sur le port 80 qui retourne 301 https://$host$request_uri. Combiné avec HSTS, le bloc HTTP sera à peine touché après la première requête.

Exécutez sudo nginx -t pour analyser la configuration sans recharger. S’il affiche “syntax is ok” et “test is successful”, rechargez avec sudo systemctl reload nginx. N’utilisez jamais restart en production : le rechargement applique la nouvelle configuration sans interrompre le trafic.

Outils similaires

Outil disponible dans d’autres langues