Générateur de configuration nginx — HTTP/3, WebSocket, sécurité

Que fait le générateur de configuration nginx ?

Le générateur est un éditeur de server blocks nginx. Vous choisissez parmi huit types de bloc (hébergement statique, fallback SPA, reverse-proxy, PHP-FPM, load-balancer, redirection seule, stream TCP, stream UDP), ajustez des champs tels que server_name, root et upstream, et le générateur agence toutes les directives nécessaires dans le bon ordre. Vous pouvez aussi coller un .htaccess existant — le générateur traduit redirections, rewrites, en-têtes et ErrorDocuments en directives nginx. Tout se passe dans le navigateur. Pas de téléversement, pas de compte, pas de bannière de cookies.

Les six presets couvrent les piles les plus fréquentes :

• SPA — hébergement statique — single-page app avec Astro/SvelteKit/Vite, long-cache pour les assets hashés, fallback sur index.html, HTTP/3 actif.
• Node.js — reverse-proxy — serveur Node/Bun derrière nginx avec upgrade WebSocket correctement câblé.
• Python — Uvicorn/ASGI — FastAPI ou Starlette via Uvicorn, rate-limit « API ».
• WordPress — PHP-FPM — PHP-FPM via socket Unix, wp-config.php et .env verrouillés.
• HTTPS strict — Audit-A — taillé pour un score A à Mozilla Observatory, TLS 1.3, COOP/COEP/CORP.
• Load-balancer — least_conn — nginx devant trois nœuds backend, failover de santé via max_fails.

Quels types de server block sont intégrés ?

Huit types, regroupés par cas :

• Hébergement statique — try_files $uri $uri/ =404;. Classique pour Hugo, 11ty, HTML pur.
• Fallback SPA — try_files $uri $uri/ /index.html; plus long-cache pour assets hashés. Standard pour toute app à routage client.
• Reverse-proxy — proxy_pass vers un upstream, avec tous les X-Forwarded-* usuels. Upgrade WebSocket optionnel.
• PHP-FPM — fastcgi_pass vers un socket Unix, avec permaliens try_files et règles deny pour wp-config.php, .env, .git.
• Load-balancer — proxy_pass http://backend_pool; plus le template upstream correspondant (commenté car upstream {} vit hors de server {}).
• Redirection seule — return 301 https://www.example.com$request_uri;. Pour les canoniques www et les migrations de domaine.
• Stream TCP — pour le scope stream {}, par exemple proxying Postgres/Redis. Le bloc commente le changement de scope.
• Stream UDP — analogue pour DNS ou QUIC-forward.

Comment fonctionne le support HTTP/3 et QUIC ?

HTTP/3 remplace HTTP/2 et utilise QUIC au lieu de TCP comme transport. QUIC est basé sur UDP, intègre TLS au setup de connexion et élimine le head-of-line blocking de HTTP/2. nginx intègre QUIC dans la build officielle depuis la version 1.25 (auparavant seulement dans la branche nginx-quic). Le générateur émet quatre directives dès l’activation de HTTP/3 :

listen 443 quic reuseport;
listen [::]:443 quic reuseport;
http3 on;
ssl_early_data on;
add_header Alt-Svc 'h3=":443"; ma=86400' always;

L’en-tête Alt-Svc signale aux navigateurs que HTTP/3 est disponible sur le port 443 ; ma=86400 met l’information en cache pendant 24 heures. Les navigateurs sans HTTP/3 ignorent l’en-tête et restent sur HTTP/2.

Pourquoi la correction de l’upgrade WebSocket compte ?

Le reverse-proxying WebSocket casse dans la plupart des configs nginx naïves parce que l’upgrade de connexion manque. Le bon motif comporte quatre parties :

1. Directive map dans le scope http {} — traduit l’en-tête Upgrade envoyé par le client en une valeur Connection adaptée :

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

2. proxy_set_header Upgrade $http_upgrade; — transmet le signal d’upgrade au backend.
3. proxy_set_header Connection $connection_upgrade; — écrase le Connection: close par défaut que nginx pose en reverse-proxy.
4. proxy_read_timeout 86400s; — place le read-timeout à 24 heures pour que les WebSockets inactifs ne se coupent pas après 60 secondes (défaut nginx).

Le générateur écrit les quatre automatiquement dès que vous cochez WebSocket dans un bloc reverse-proxy ou load-balancer. C’est le pain-point n°1 des setups WebSocket — et la cause principale des « ma connexion casse sans cesse » sur les forums.

Quels en-têtes de sécurité sont émis ?

Six en-têtes appartiennent à tout bloc nginx moderne (voir les Mozilla Web Security Guidelines) :

• Strict-Transport-Security — HSTS avec max-age=31536000; includeSubDomains; preload. Preload est actif par défaut, un toggle permet de le couper pour les sous-domaines qui ne fonctionnent pas sans HTTP.
• Content-Security-Policy — valeur de départ avec default-src 'self', frame-ancestors 'none'. Toggle pour le mode report-only pendant le déploiement.
• Permissions-Policy — tout désactivé par défaut (camera=(), microphone=(), geolocation=(), payment=(), usb=(), interest-cohort=(), browsing-topics=()).
• Cross-Origin-Opener-Policy — same-origin contre les attaques window.opener.
• Cross-Origin-Embedder-Policy — optionnel require-corp pour les cas SharedArrayBuffer.
• Cross-Origin-Resource-Policy — same-origin bloque les intégrations cross-origin de vos propres assets.

Chaque en-tête porte le flag always. Sans always, nginx supprime les en-têtes sur les réponses 4xx/5xx — ce que de nombreux outils d’audit (Mozilla Observatory, securityheaders.com) classent comme infraction A. Avant le déploiement, validez votre CSP avec l’évaluateur CSP externe.

Comment fonctionne le profil de rate-limit ?

Le rate-limiting nginx combine deux directives :

• limit_req_zone dans le scope http {} — réserve la mémoire partagée et définit le débit.
• limit_req zone=<nom> burst=<n> nodelay; dans le bloc location — référence la zone.

Erreur fréquente des générateurs en ligne publics : la zone est émise, la référence dans location manque — la zone reste totalement inutilisée (voir l’issue ouverte sur le générateur en ligne le plus populaire). Le générateur émet les deux ensemble et injecte la référence dans le premier location du server block. Trois profils :

• Gentle — 30 r/s, burst 50, limit_conn 100. Pour les sites web avec un vrai trafic utilisateur.
• API — 10 r/s, burst 20, limit_conn 50. Pour les APIs REST/GraphQL avec throttling sur token.
• Strict — 5 r/s, burst 10, limit_conn 20. Pour les endpoints de login, les receivers de webhooks, les routes critiques.

burst définit combien de requêtes en plus du débit sont acceptées avant que les 429 ne sortent. nodelay signifie que les requêtes en burst sont traitées immédiatement, sans temporisation au rythme du débit. Sans nodelay, nginx retarderait artificiellement une requête en burst — pas le comportement souhaité en pratique.

Que fait le convertisseur .htaccess vers nginx ?

Apache et nginx ont des modèles de configuration différents : Apache relit .htaccess à chaque requête (coûteux mais souple), nginx analyse sa configuration une fois au reload (rapide mais sans override par requête). Il n’y a pas de conversion 1:1 complète, mais les directives clés sont mappables :

Apache	nginx
Redirect 301 /old /new	rewrite ^/old$ /new permanent;
Redirect 302 /a /b	rewrite ^/a$ /b redirect;
RewriteRule ^foo$ /bar [L]	rewrite ^foo$ /bar last;
RewriteRule … [R=301,L]	rewrite … permanent;
Header always set X-Frame-Options DENY	add_header X-Frame-Options "DENY" always;
ErrorDocument 404 /404.html	error_page 404 /404.html;
Options -Indexes	autoindex off;
Require ip 192.168.1.1	allow 192.168.1.1;
Deny from 203.0.113.4	deny 203.0.113.4;
<IfModule>	commenté à plat (nginx n’a pas de conditionnel par module)

Les directives non mappables reviennent en commentaire # TODO (could not convert): …. Le convertisseur est déterministe — la même entrée donne toujours la même sortie, pas de rate-limit IA, pas d’aller-retour cloud. L’avertissement en tête (« coller à l’intérieur de votre bloc server { ... } ») est obligatoire à lire — les directives émises doivent atterrir dans le bon scope.

Quels pain-points le générateur évite-t-il ?

Quatre classiques qui reviennent dans les tutoriels nginx — et que le générateur évite :

1. WebSocket coupe après 60 secondes — cause la plus fréquente : proxy_read_timeout 86400s; manquant plus en-têtes d’upgrade incorrects. Le générateur pose les deux automatiquement.
2. Zone de rate-limit sans référence — la limit_req_zone est émise, mais limit_req dans le bloc location manque. Effet : zéro. Le générateur émet les deux ensemble.
3. En-têtes de sécurité absents sur les pages d’erreur — sans always, nginx supprime les en-têtes sur les réponses 4xx/5xx. Le générateur pose always sur chaque add_header.
4. HTTP/3 mal configuré — reuseport manquant, ssl_early_data absent, pas d’en-tête Alt-Svc. Le générateur émet les quatre directives dès l’activation de HTTP/3.

Comment est gérée la confidentialité ?

100 % côté client. Le générateur tourne intégralement dans le navigateur. Aucun endpoint serveur pour valider la configuration, aucun appel de télémétrie, aucun cookie, aucun compte. Si vous fermez l’onglet, vos réglages disparaissent — le générateur ne persiste rien. Pour conserver un historique, téléchargez la nginx.conf après chaque édition et versionnez-la dans votre dépôt.

Ce qui n’a volontairement pas été construit

• Pas de validation en direct avec nginx -t — exigerait un aller-retour serveur ou un portage WebAssembly de nginx lui-même. À la place, l’entête du générateur et l’astuce UI renvoient à sudo nginx -t après déploiement.
• Pas d’émission automatique de Let’s Encrypt — le générateur ne fournit que le snippet webroot Certbot. L’activation du certificat demande un accès serveur et sort du périmètre navigateur.
• Pas de mode GUI Nginx Proxy Manager — pour un workflow GUI-first, utilisez directement Nginx Proxy Manager. Ce générateur s’adresse aux devs qui gardent la config comme du code.
• Pas de règles ngx_mod_security — le tuning WAF est un outil à part (trop spécialisé, trop dépendant des rulesets).
• Pas de variante Apache 2.2 — .htaccess 2.2 est couvert par l’outil sœur htaccess-generator.
• Pas d’éditeur de profil de caching — les défauts gzip et la règle long-cache du bloc SPA couvrent 90 % des cas.

Où trouver plus de détails ?

• Documentation nginx — référence officielle des directives
• nginx sur Wikipédia — histoire, architecture, usages
• Mozilla SSL Configuration Generator — référence des profils TLS
• hstspreload.org — liste de soumission pour les domaines HSTS-preload
• CSP Evaluator — validateur externe de Content-Security-Policy
• RFC 9114 (HTTP/3) — spécification HTTP/3
• Cloudflare Learning Center — WebSocket — bases du protocole WebSocket