Générateur de configuration Nginx

Le Générateur de Configuration Nginx est un outil en ligne gratuit qui génère des configurations Nginx prêtes pour la production avec SSL, reverse proxy, php-fpm, gzip, mise en cache, en-têtes de sécurité, limitation de débit et redirections. 7 préréglages inclus. Il fonctionne entièrement dans votre navigateur, sans installation ni inscription.

Sept : Site statique, WordPress, Node.js, Laravel, Next.js, Django et SPA (React/Vue). Chacun préremplit les paramètres appropriés.

Génère un bloc server pour nginx.conf ou sites-available. Les directives de zone de limitation de débit sont affichées en commentaires pour le bloc http.

Non. Tout s'exécute côté client, dans votre navigateur.

Oui, le Générateur de Configuration Nginx est 100 % gratuit, sans inscription, sans frais cachés et sans limite d'utilisation. Tout le traitement se fait localement dans votre navigateur, garantissant une confidentialité totale.

Absolument. Le Générateur de Configuration Nginx traite tout côté client, dans votre navigateur. Aucune donnée n'est téléchargée ni stockée sur un serveur. Votre contenu reste privé sur votre appareil à tout moment.

Oui, le Générateur de Configuration Nginx est entièrement responsive et fonctionne sur smartphones et tablettes. Vous pouvez l'utiliser sur n'importe quel appareil doté d'un navigateur web moderne, sans aucune application à télécharger.

Aucun compte ni inscription n'est nécessaire. Ouvrez simplement le Générateur de Configuration Nginx dans votre navigateur et utilisez-le immédiatement. Il n'y a ni barrière d'inscription ni restriction d'utilisation.

Saisissez simplement vos données dans le champ prévu, ajustez les paramètres selon vos préférences, et l'outil les traitera instantanément. Vous pouvez ensuite copier le résultat dans le presse-papiers ou le télécharger.

Le Générateur de Configuration Nginx fonctionne dans tous les navigateurs modernes, dont Chrome, Firefox, Safari, Edge et Opera. Pour une expérience optimale, utilisez la dernière version de votre navigateur préféré.

Dans Nginx, la limitation de débit repose sur deux éléments qui vivent dans des contextes différents. La directive limit_req_zone définit une zone de mémoire partagée (par exemple zone=ratelimit:10m rate=...) et n'est valide que dans le bloc http de premier niveau, car cette zone est partagée entre tous les blocs server. La directive limit_req correspondante, qui applique réellement la limite avec une valeur de burst, se place quant à elle dans le bloc server ou location. Si vous collez limit_req_zone dans un bloc server, Nginx refuse de démarrer avec une erreur du type « directive is not allowed here ». C'est pourquoi ce générateur place la ligne limit_req directement dans votre bloc serveur mais émet la ligne limit_req_zone sous forme de commentaire étiqueté, pour vous rappeler de la déplacer dans le contexte http. Activez la limitation de débit dans l'outil et copiez les deux éléments au bon endroit.

Une configuration en proxy inverse utilise proxy_pass pour transmettre les requêtes à un serveur d'application distinct tournant sur son propre port, comme un processus Node.js, Next.js ou Django/Gunicorn sur 127.0.0.1:3000 ou :8000. Nginx ajoute des en-têtes comme X-Real-IP, X-Forwarded-For, X-Forwarded-Proto et Host, ainsi que les en-têtes Upgrade et Connection lorsque les WebSockets sont activés. Une configuration PHP-FPM utilise à la place un bloc location ~ \.php$ avec fastcgi_pass pointant vers un socket Unix et inclut fastcgi_params, si bien que Nginx transmet directement les fichiers PHP au processus FPM plutôt que de faire un proxy HTTP. WordPress et Laravel empruntent la voie FastCGI ; Node, Next.js et Django empruntent la voie du proxy inverse. Choisissez le préréglage correspondant dans le générateur, et il configure automatiquement les bonnes directives pour votre stack.

Les deux redirections se gèrent proprement au sein d'une même configuration de blocs serveur. Pour le passage de HTTP à HTTPS, un serveur distinct écoutant sur le port 80 intercepte les requêtes en clair et émet un 301 vers la version https://, tandis que votre serveur principal écoute sur le port 443 avec SSL. Pour la canonicalisation www contre non-www, vous redirigez un hôte vers l'autre, également avec un 301, afin que les moteurs de recherche et les navigateurs se fixent sur un seul domaine canonique au lieu de traiter www et la racine comme des sites dupliqués. Faire cela à la main expose à des boucles de redirection si les règles se chevauchent ou si une directive atterrit dans le mauvais bloc serveur. Activez le passage HTTP vers HTTPS et votre option www ou non-www préférée dans le générateur, et il écrit pour vous les blocs de redirection dans le bon ordre, prêts à copier.

Ajouter http2 à la ligne listen 443 ssl active HTTP/2, qui multiplexe de nombreuses requêtes sur une seule connexion et accélère nettement les pages chargées en ressources, sans aucun changement côté application. Restreindre ssl_protocols à TLSv1.2 et TLSv1.3 élimine les anciens protocoles SSLv3, TLS 1.0 et TLS 1.1, obsolètes et vulnérables à des attaques comme POODLE et BEAST, de sorte que les clients modernes ne négocient que des suites de chiffrement sécurisées. Le générateur ajoute également une suite de chiffrement renforcée, un cache de session, HSTS optionnel avec preload, et l'agrafage OCSP afin que les vérifications de révocation de certificat ne ralentissent pas la poignée de main. Ce sont des réglages par défaut que l'on oublie souvent en écrivant une configuration à la main. Activez la section SSL dans l'outil et ces paramètres sont remplis pour vous, prêts à être vérifiés avant le déploiement.

Les applications monopages (SPA) gèrent le routage en JavaScript, donc lorsqu'un utilisateur actualise un lien profond comme /dashboard, le navigateur demande à Nginx un fichier réel à ce chemin. Sans traitement particulier, Nginx renvoie une erreur 404 car aucun fichier de ce nom n'existe sur le disque. La solution est une directive try_files qui se replie sur votre index.html : try_files $uri $uri/ /index.html;. Cela sert les véritables ressources statiques lorsqu'elles existent, mais renvoie tout chemin inconnu vers la coquille de l'application, laissant le routeur client prendre le relais. Oublier cette ligne est la cause la plus fréquente de rupture des SPA lors d'une actualisation en production. Le préréglage SPA (React/Vue) de ce générateur met en place automatiquement ce repli d'historique, ainsi que la compression gzip et la mise en cache des ressources, il ne reste plus qu'à copier le résultat pour que vos routes survivent à une actualisation forcée.