Comment nginx décide quel server-block utiliser pour une requête entrante ?

Il regarde l'**en-tête Host** que le navigateur a envoyé et le matche contre le [[server_name||la directive qui liste les domaines auxquels un bloc répond]] de chaque bloc écoutant sur le même port. Priorité de match : le **nom exact** gagne (`exemple.fr`), puis le **wildcard de tête** (`*.exemple.fr`), puis le **wildcard de queue** (`exemple.*`), puis la **regex**. Si rien ne matche, le **default_server** pour ce port est utilisé (le premier bloc sur ce port si aucun n'est explicitement marqué). C'est pourquoi vos bugs "le mauvais site s'affiche" concernent presque toujours server_name.

Quelle est la différence entre `listen 80` et `listen 443 ssl` ?

**Le port 80** est HTTP simple, sans chiffrement. **Le port 443** est HTTPS, et le flag `ssl` dit à nginx de faire des handshakes TLS sur ce socket et de lire `ssl_certificate` et `ssl_certificate_key`. Un site moderne a besoin des **deux blocs** : un sur 80 qui redirige vers https, un sur 443 qui fait le vrai travail. Ce builder génère cette paire quand vous activez *Ajouter la redirection HTTP vers HTTPS* en plus de *Ajouter le bloc SSL*.

Comment les blocs [[location||un bloc qui matche une partie du chemin URL et y applique des règles]] choisissent lequel s'applique ?

Priorité de match, dans l'ordre : le **match exact** (`location = /favicon.ico`) gagne ; puis le **préfixe le plus long avec `^~`** gagne d'office ; puis la **regex** (`location ~ \.php$`) est vérifiée dans l'ordre ; puis le **préfixe régulier** (`location /api`). Une fois qu'une regex matche, nginx arrête de chercher, mettez donc les règles les plus spécifiques en premier. Pour un seul site statique ou proxy, un `location /` suffit.

Pourquoi `proxy_pass http://app/` (avec slash final) se comporte différemment de `proxy_pass http://app` (sans) ?

Avec un **slash final**, nginx **retire le préfixe de location** de la requête avant de transférer. `location /api/ { proxy_pass http://app/; }` transforme `/api/users` en `/users` pour le backend. **Sans** slash final, il transfère **tel quel** : `/api/users` reste `/api/users`. Les deux sont valides, les deux piègent les gens qui oublient lequel ils ont écrit. Astuce : si votre backend est monté à `/`, utilisez un slash final des deux côtés. S'il attend le préfixe, n'utilisez pas de slash final.

Quand utiliser [[try_files||une directive qui dit à nginx quels chemins essayer dans l'ordre, et quoi faire quand aucun n'existe]] au lieu de juste `index` ?

Utilisez `try_files` pour **tout ce qui n'est pas un dossier plat de fichiers HTML**. Les single-page apps (React, Vue, Svelte) ont besoin de `try_files $uri $uri/ /index.html;` pour que rafraîchir sur `/dashboard/parametres` charge encore `index.html` et que le router prenne le relais. WordPress et similaires ont besoin de `try_files $uri $uri/ /index.php?$args;`. La simple directive `index index.html;` ne se déclenche que quand l'URL pointe sur un dossier.

Comment marche la config Cloudflare real-IP réellement ?

Quand Cloudflare proxyfie une requête, votre nginx voit l'IP Cloudflare dans `$remote_addr` et la vraie IP client dans un en-tête appelé `CF-Connecting-IP`. Le bloc ajoute deux pièces : **`set_real_ip_from ;`** pour chaque plage publiée Cloudflare (pour que nginx leur fasse confiance comme proxies) et **`real_ip_header CF-Connecting-IP;`** qui dit à nginx d'écraser `$remote_addr` depuis cet en-tête. Après reload, vos logs d'accès, rate limits et règles fail2ban voient à nouveau la vraie IP visiteur. Mettez à jour les plages tous les quelques mois depuis `cloudflare.com/ips`.

Dois-je choisir gzip ou brotli ?

Utilisez **gzip** quand vous voulez un drop-in d'une ligne qui marche partout d'office. Utilisez **brotli** quand vous pouvez installer le module tiers et voulez des payloads **15 à 25 % plus petits** pour le contenu texte. La plupart des sites en prod activent **les deux** (`gzip on; brotli on;`) et laissent le client négocier via `Accept-Encoding`. Ce builder livre gzip parce qu'il est intégré dans nginx stock. Brotli a besoin de `libnginx-mod-brotli` sur Debian ou de compiler depuis les sources.

Pourquoi ai-je besoin des en-têtes Upgrade [[WebSocket||un protocole qui garde une connexion bidirectionnelle long-vivante entre navigateur et serveur]] ?

Un WebSocket démarre comme une requête HTTP/1.1 normale avec les en-têtes `Upgrade: websocket` et `Connection: Upgrade`, puis **bascule en connexion persistante bidirectionnelle**. Par défaut nginx est en HTTP/1.0 vers le backend et retire les en-têtes hop-by-hop, l'upgrade ne se passe donc jamais et votre chat ou dashboard live se bloque. Les quatre lignes qu'on génère (`proxy_http_version 1.1`, `proxy_set_header Upgrade`, `proxy_set_header Connection "upgrade"`, `proxy_read_timeout 86400`) règlent tout ça.

Où mettre le fichier et comment faire nginx le prendre ?

**1.** Sauvegardez le fichier dans `/etc/nginx/sites-available/ .conf` (convention Debian / Ubuntu, Red Hat utilise `/etc/nginx/conf.d/`). **2.** Rendez-le actif en symlinkant : `sudo ln -s /etc/nginx/sites-available/ .conf /etc/nginx/sites-enabled/`. **3.** Validez la syntaxe : `sudo nginx -t`. Si vous voyez `syntax is ok` et `test is successful`, vous êtes bon. **4.** Rechargez nginx : `sudo systemctl reload nginx` (reload, pas restart, pour que les connexions existantes survivent). Oublier **`nginx -t`** est la manière la plus courante de mettre un site hors ligne.

Builder config Nginx - gratuit

ModeChoisissez ce que vous construisez

Common

server_nameDomaines pour lesquels ce bloc répond. Un par ligne, ex : `exemple.com` ou `www.exemple.com`

Listen port

Habituellement 80 pour HTTP, 443 pour HTTPS, 8080 pour une appli derrière un proxy

Ajouter un bloc SSL (HTTPS)

Ajoute `listen 443 ssl`, les chemins Let's Encrypt et des ciphers modernes

Domaine pour le certificatUtilisé dans les chemins `/etc/letsencrypt/live/'<domain>'/…`. Généralement votre premier server_name

Ajouter une redirection HTTP vers HTTPS

Second server-block sur le port 80 qui redirige en 301 vers https

Reverse proxy

Adresse du backend (proxy_pass)URL complète de l'appli derrière le proxy. Ex : `http://127.0.0.1:3000`

Définir les en-têtes X-Forwarded-*

Passe l'IP client, l'hôte et le schéma à l'appli amont

Add-ons

Ajouter gzip (compression des réponses)

Réduit HTML, CSS, JS, JSON. Ignoré pour les images et la vidéo

Ajouter les en-têtes WebSocket Upgrade

Nécessaire si l'appli utilise des WebSockets (Socket.IO, Phoenix Channels, etc.)

Ajouter la vraie IP Cloudflare

Restaure l'IP client d'origine dans les logs et `$remote_addr` plutôt que celle de Cloudflare

server-block nginx

api.example.com.conf

39 lines

# HTTP → HTTPS redirect
server {
    listen 80;
    listen [::]:80;
    server_name api.example.com;
    return 301 https://$host$request_uri;
}

server {
    listen 443 ssl;
    listen [::]:443 ssl;
    http2 on;
    server_name api.example.com;

    # SSL (Let's Encrypt)
    ssl_certificate     /etc/letsencrypt/live/api.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/api.example.com/privkey.pem;
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_prefer_server_ciphers off;
    ssl_session_cache shared:SSL:10m;
    ssl_session_timeout 1d;
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;

    # Gzip compression
    gzip on;
    gzip_vary on;
    gzip_comp_level 5;
    gzip_min_length 256;
    gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript image/svg+xml;

    location / {
      proxy_pass http://127.0.0.1:3000;
      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 X-Forwarded-Host $host;
    }
}

How to deploy

Sauvegardez dans `/etc/nginx/sites-available/'<name>'.conf`
Faites un symlink : `ln -s /etc/nginx/sites-available/'<name>'.conf /etc/nginx/sites-enabled/`
Vérifiez la syntaxe : `sudo nginx -t`
Rechargez : `sudo systemctl reload nginx`

Ce que ce générateur vous donne

Si vous avez déjà ouvert un fichier `.conf` vide sous `/etc/nginx/sites-available/` en vous demandant par où commencer, cet outil est pour vous. Il écrit le server-block entier pour les cinq choses que les gens font vraiment avec nginx : servir un site statique, mettre un reverse proxy devant une app, lancer une redirection propre, héberger un sous-domaine, ou répartir le trafic sur plusieurs backends avec un load balancer.

Choisissez un mode en haut, remplissez un domaine et un backend, basculez les switches pour SSL, gzip, WebSockets et Cloudflare. Le panneau de droite montre le texte exact que vous collez dans nginx, indenté et stylé comme une vraie config. Copier ou Télécharger comme `<votre-domaine>.conf`.

Tout tourne dans votre navigateur. Aucun domaine n'est résolu, aucun cert n'est émis, rien n'est uploadé. La sortie est de la syntaxe nginx pure, identique à ce que vous taperiez à la main si vous aviez mémorisé chaque directive.

Mode d'emploi

Choisissez un mode en haut : *Site statique*, *Reverse proxy*, *Redirection*, *Sous-domaine* ou *Load balancer*. Chaque mode ne montre que les champs qui comptent pour lui.

Tapez vos domaines dans server_name. Un domaine par ligne. Le premier est utilisé comme nom de certificat.

Choisissez le port listen. 80 pour HTTP simple, 443 pour HTTPS, 8080 quand un proxy upstream ou Docker gère le TLS.

Activez Ajouter le bloc SSL pour câbler les chemins Let's Encrypt (`/etc/letsencrypt/live/<domain>/fullchain.pem`). Laissez Ajouter la redirection HTTP vers HTTPS activée pour que les visiteurs HTTP simples soient renvoyés vers https avec un `301`.

Pour le Reverse proxy : mettez proxy_pass vers votre backend, par exemple `http://127.0.0.1:3000`. Gardez les en-têtes X-Forwarded- activés pour que votre app voie la vraie IP client.

Pour le Load balancer : collez un `address:port` par ligne dans *Serveurs backend* et choisissez un algorithme. Utilisez les groupes upstream avec `least_conn` pour les apps lentes et `ip_hash` quand vous avez besoin de sessions sticky.

Si votre app utilise des WebSockets (Socket.IO, Phoenix Channels, etc.) activez Ajouter les en-têtes Upgrade WebSocket. Si vous mettez Cloudflare devant nginx, activez Ajouter Cloudflare real IP pour que les logs montrent le vrai client.

Cliquez sur Copier, collez dans `/etc/nginx/sites-available/<votre-fichier>.conf`, symlinkez vers `sites-enabled`, lancez `sudo nginx -t` pour valider la syntaxe, puis `sudo systemctl reload nginx`.

Quand cet outil est utile

Sept situations où un server-block prêt à l'emploi évite beaucoup de plissements d'yeux sur la doc :

Vous avez déployé une app Node, Python ou Go sur un VPS et voulez la mettre sur le port 443 avec un vrai cert TLS. Choisissez *Reverse proxy*, pointez vers `http://127.0.0.1:3000`, activez SSL, fini. Nginx termine le TLS, votre app reste en HTTP simple derrière.
Vous avez acheté un domaine pour une landing page statique. Choisissez *Site statique*, pointez root vers `/var/www/votre-site` et vous obtenez un server-block fonctionnel avec les bons fichiers index et un fallback try_files.
Vous migrez un vieux domaine vers un nouveau. Choisissez *Redirection*, cible `https://nouveau.exemple.fr$request_uri`, code `301`. Google met à jour l'index, les navigateurs cachent la redirection, vos vieux liens continuent de marcher.
Vous voulez un sous-domaine pour un blog. Choisissez *Sous-domaine*, préfixe `blog`, base `exemple.fr` et vous obtenez un server-block complet `blog.exemple.fr`. Sauvegardez sous ce nom de fichier exact pour garder `sites-available/` rangé.
Votre app ne tient pas la charge sur une seule boîte. Choisissez *Load balancer*, collez trois ou quatre lignes backend `address:port`, choisissez `least_conn` et nginx route chaque requête vers la moins occupée. Ajouter un serveur c'est une nouvelle ligne.
Votre chat temps réel est cassé derrière nginx à cause des WebSockets. Activez *Ajouter les en-têtes Upgrade WebSocket* et nginx forwarde correctement `Upgrade` et `Connection`, avec un timeout de lecture de 24h qui survit aux connexions long-vivantes.
Vous êtes derrière Cloudflare et tous vos logs disent "172.x.x.x". Activez *Ajouter Cloudflare real IP*, nginx réécrit `$remote_addr` depuis l'en-tête `CF-Connecting-IP` venant des plages Cloudflare. Les rate limits, fail2ban et logs d'audit remarchent.

Questions fréquentes

Nginx est un serveur web et un reverse proxy qui écoute sur un port (généralement 80 ou 443), prend les requêtes HTTP entrantes, et décide quoi faire de chacune. Il peut servir des fichiers depuis le disque (comme un site statique), transférer la requête à un autre programme tournant sur la même machine (une app sur `127.0.0.1:3000`, c'est le mode reverse-proxy), rediriger vers une autre URL, ou répartir le trafic sur plusieurs serveurs backend. C'est la porte d'entrée standard pour presque toutes les stacks web Linux et la chose qui gère votre terminaison SSL/TLS.

choisissent lequel s'applique ?

au lieu de juste `index` ?

# HTTP → HTTPS redirect server { listen 80; listen [::]:80; server_name api.example.com; return 301 https://$host$request_uri; } server { listen 443 ssl; listen [::]:443 ssl; http2 on; server_name api.example.com; # SSL (Let's Encrypt) ssl_certificate /etc/letsencrypt/live/api.example.com/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/api.example.com/privkey.pem; ssl_protocols TLSv1.2 TLSv1.3; ssl_prefer_server_ciphers off; ssl_session_cache shared:SSL:10m; ssl_session_timeout 1d; add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always; # Gzip compression gzip on; gzip_vary on; gzip_comp_level 5; gzip_min_length 256; gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript image/svg+xml; location / { proxy_pass http://127.0.0.1:3000; 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 X-Forwarded-Host $host; } }

Ce que ce générateur vous donne

Mode d'emploi

Choisissez un mode en haut : *Site statique*, *Reverse proxy*, *Redirection*, *Sous-domaine* ou *Load balancer*. Chaque mode ne montre que les champs qui comptent pour lui.

Tapez vos domaines dans server_name. Un domaine par ligne. Le premier est utilisé comme nom de certificat.

Choisissez le port listen. 80 pour HTTP simple, 443 pour HTTPS, 8080 quand un proxy upstream ou Docker gère le TLS.

Pour le Reverse proxy : mettez proxy_pass vers votre backend, par exemple `http://127.0.0.1:3000`. Gardez les en-têtes X-Forwarded- activés pour que votre app voie la vraie IP client.

Quand cet outil est utile

Sept situations où un server-block prêt à l'emploi évite beaucoup de plissements d'yeux sur la doc :

Vous avez déployé une app Node, Python ou Go sur un VPS et voulez la mettre sur le port 443 avec un vrai cert TLS. Choisissez *Reverse proxy*, pointez vers `http://127.0.0.1:3000`, activez SSL, fini. Nginx termine le TLS, votre app reste en HTTP simple derrière.
Vous avez acheté un domaine pour une landing page statique. Choisissez *Site statique*, pointez root vers `/var/www/votre-site` et vous obtenez un server-block fonctionnel avec les bons fichiers index et un fallback try_files.
Vous migrez un vieux domaine vers un nouveau. Choisissez *Redirection*, cible `https://nouveau.exemple.fr$request_uri`, code `301`. Google met à jour l'index, les navigateurs cachent la redirection, vos vieux liens continuent de marcher.
Vous voulez un sous-domaine pour un blog. Choisissez *Sous-domaine*, préfixe `blog`, base `exemple.fr` et vous obtenez un server-block complet `blog.exemple.fr`. Sauvegardez sous ce nom de fichier exact pour garder `sites-available/` rangé.
Votre app ne tient pas la charge sur une seule boîte. Choisissez *Load balancer*, collez trois ou quatre lignes backend `address:port`, choisissez `least_conn` et nginx route chaque requête vers la moins occupée. Ajouter un serveur c'est une nouvelle ligne.
Votre chat temps réel est cassé derrière nginx à cause des WebSockets. Activez *Ajouter les en-têtes Upgrade WebSocket* et nginx forwarde correctement `Upgrade` et `Connection`, avec un timeout de lecture de 24h qui survit aux connexions long-vivantes.
Vous êtes derrière Cloudflare et tous vos logs disent "172.x.x.x". Activez *Ajouter Cloudflare real IP*, nginx réécrit `$remote_addr` depuis l'en-tête `CF-Connecting-IP` venant des plages Cloudflare. Les rate limits, fail2ban et logs d'audit remarchent.

Questions fréquentes

choisissent lequel s'applique ?

au lieu de juste `index` ?

Builder config Nginx

Ce que ce générateur vous donne

Mode d'emploi

Quand cet outil est utile

Questions fréquentes

Outils similaires

Builder config SSH

Lookup DNS

Inspecteur certificat SSL

Inspecteur en-têtes HTTP

Builder unit systemd

Builder config Nginx

Ce que ce générateur vous donne

Mode d'emploi

Quand cet outil est utile

Questions fréquentes

Outils similaires

Builder config SSH

Lookup DNS

Inspecteur certificat SSL

Inspecteur en-têtes HTTP

Builder unit systemd