How does nginx decide which server-block to use for an incoming request?

It looks at the **Host header** the browser sent and matches it against the [[server_name||the directive that lists the domains a block answers for]] of each block listening on the same port. Match priority: **exact name** wins (`example.com`), then **leading wildcard** (`*.example.com`), then **trailing wildcard** (`example.*`), then **regex**. If nothing matches, the **default_server** for that port is used (the first block on that port if none is explicitly marked). That is why your "wrong site is showing" bugs are almost always about server_name.

What is the difference between `listen 80` and `listen 443 ssl`?

**Port 80** is plain HTTP, no encryption. **Port 443** is HTTPS, and the `ssl` flag tells nginx to do TLS handshakes on that socket and read `ssl_certificate` and `ssl_certificate_key`. A modern site needs **both blocks**: one on 80 that redirects to https, one on 443 that does the real work. This builder generates that pair when you flip *Add HTTP to HTTPS redirect* on top of *Add SSL block*.

How do nginx [[location||a block that matches part of the URL path and applies rules to it]] blocks pick which one to apply?

Match priority, in order: **exact match** (`location = /favicon.ico`) wins; then **longest prefix with `^~`** wins outright; then **regex** (`location ~ \.php$`) is checked in order; then **regular prefix** (`location /api`). Once a regex matches, nginx stops looking, so put the most specific rules first. For a single static or proxy site, one `location /` is enough.

Why does `proxy_pass http://app/` (with trailing slash) behave differently from `proxy_pass http://app` (without)?

With a **trailing slash**, nginx **strips the location prefix** from the request before forwarding. `location /api/ { proxy_pass http://app/; }` turns `/api/users` into `/users` for the backend. **Without** a trailing slash, it forwards **as is**: `/api/users` stays `/api/users`. Both are valid, both bite people who forget which one they wrote. Tip: if your backend is mounted at `/`, use a trailing slash on both sides. If it expects the prefix, use no trailing slash.

When should I use [[try_files||a directive that tells nginx which paths to try in order, and what to do when none exist]] instead of just `index`?

Use `try_files` for **anything that is not a flat folder of HTML files**. Single-page apps (React, Vue, Svelte) need `try_files $uri $uri/ /index.html;` so refreshing on `/dashboard/settings` still loads `index.html` and the router takes over. WordPress and similar need `try_files $uri $uri/ /index.php?$args;`. The plain `index index.html;` directive only kicks in when the URL points at a directory.

How does the Cloudflare real-IP setup actually work?

When Cloudflare proxies a request, your nginx sees Cloudflare's IP in `$remote_addr` and the real client IP in a header called `CF-Connecting-IP`. The block adds two pieces: **`set_real_ip_from ;`** for every Cloudflare published range (so nginx trusts them as proxies) and **`real_ip_header CF-Connecting-IP;`** which tells nginx to overwrite `$remote_addr` from that header. After reload, your access logs, rate limits, and fail2ban rules see the real visitor IP again. Update the ranges every few months from `cloudflare.com/ips`.

Should I pick gzip or brotli?

Use **gzip** when you want a one-line drop-in that works everywhere out of the box. Use **brotli** when you can install the third-party module and want **15 to 25 percent smaller** payloads for text content. Most production sites enable **both** (`gzip on; brotli on;`) and let the client negotiate via `Accept-Encoding`. This builder ships gzip because it is built into stock nginx. Brotli needs `libnginx-mod-brotli` on Debian or compiling from source.

Why do I need [[WebSocket||a protocol that keeps a long-lived two-way connection open between browser and server]] Upgrade headers?

A WebSocket starts as a normal HTTP/1.1 request with `Upgrade: websocket` and `Connection: Upgrade` headers, then **flips into a persistent two-way connection**. By default nginx is HTTP/1.0 to the backend and strips hop-by-hop headers, so the upgrade never happens and your chat or live dashboard hangs. The four lines we generate (`proxy_http_version 1.1`, `proxy_set_header Upgrade`, `proxy_set_header Connection "upgrade"`, `proxy_read_timeout 86400`) fix all of it.

Where do I put the file and how do I make nginx pick it up?

**1.** Save the file to `/etc/nginx/sites-available/ .conf` (Debian / Ubuntu convention, Red Hat uses `/etc/nginx/conf.d/`). **2.** Make it active by symlinking: `sudo ln -s /etc/nginx/sites-available/ .conf /etc/nginx/sites-enabled/`. **3.** Validate the syntax: `sudo nginx -t`. If you see `syntax is ok` and `test is successful`, you are good. **4.** Reload nginx: `sudo systemctl reload nginx` (reload, not restart, so existing connections survive). Forgetting **`nginx -t`** is the most common way to take a site down.

Nginx Config Snippet Builder - free

ModePick what you are building

Common

server_nameDomains this block answers for. One per line, e.g. `example.com` or `www.example.com`

Listen port

Usually 80 for HTTP, 443 for HTTPS, 8080 for an app behind a proxy

Add SSL block (HTTPS)

Adds `listen 443 ssl`, Let's Encrypt paths and modern ciphers

Domain for the certificateUsed in `/etc/letsencrypt/live/'<domain>'/...` paths. Usually your first server_name

Add HTTP to HTTPS redirect

Second server-block on port 80 that 301-redirects to https

Reverse proxy

Backend address (proxy_pass)Full URL of the app behind the proxy. e.g. `http://127.0.0.1:3000`

Set X-Forwarded-* headers

Passes the client IP, host and scheme through to the upstream app

Add-ons

Add gzip (response compression)

Shrinks HTML, CSS, JS, JSON. Skipped for images and video

Add WebSocket Upgrade headers

Needed if the app uses WebSockets (Socket.IO, Phoenix Channels, etc.)

Add Cloudflare real IP

Restores the original client IP in logs and `$remote_addr` instead of Cloudflare's

nginx server-block

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

Save to `/etc/nginx/sites-available/'<name>'.conf`
Symlink it: `ln -s /etc/nginx/sites-available/'<name>'.conf /etc/nginx/sites-enabled/`
Check syntax: `sudo nginx -t`
Reload: `sudo systemctl reload nginx`

What this builder gives you

If you have ever opened an empty `.conf` file under `/etc/nginx/sites-available/` and wondered where to even start, this tool is for you. It writes the whole server-block for the five things people actually do with nginx: serve a static site, put a reverse proxy in front of an app, run a clean redirect, host a subdomain, or spread traffic across many backends with a load balancer.

Pick a mode at the top, fill in a domain and a backend, flip the switches for SSL, gzip, WebSockets and Cloudflare. The right panel shows the exact text you paste into nginx, indented and styled like a real config. Copy or Download it as `<your-domain>.conf`.

Everything runs in your browser. No domains are resolved, no certs are issued, nothing is uploaded. The output is plain nginx syntax, identical to what you would type by hand if you had memorized every directive.

How to use it

Pick a mode at the top: *Static site*, *Reverse proxy*, *Redirect*, *Subdomain* or *Load balancer*. Each mode shows only the fields that matter for it.

Type your domains in server_name. One domain per line. The first one is used as the certificate name.

Pick the listen port. 80 for plain HTTP, 443 for HTTPS, 8080 when an upstream proxy or Docker handles TLS.

Flip Add SSL block to wire up Let's Encrypt paths (`/etc/letsencrypt/live/<domain>/fullchain.pem`). Leave Add HTTP to HTTPS redirect on so plain HTTP visitors are bounced to https with a `301`.

For Reverse proxy: set proxy_pass to your backend, e.g. `http://127.0.0.1:3000`. Keep X-Forwarded- headers on so your app sees the real client IP.

For Load balancer: paste one `address:port` per line in *Backend servers* and pick an algorithm. Use upstream groups with `least_conn` for slow apps and `ip_hash` when you need sticky sessions.

If your app uses WebSockets (Socket.IO, Phoenix Channels, etc.) flip Add WebSocket Upgrade headers. If you front nginx with Cloudflare, flip Add Cloudflare real IP so logs show the real client.

Click Copy, paste into `/etc/nginx/sites-available/<your-file>.conf`, symlink to `sites-enabled`, run `sudo nginx -t` to validate syntax, then `sudo systemctl reload nginx`.

When this is useful

Seven situations where a ready-made server-block saves a lot of squinting at docs:

You deployed a Node, Python or Go app on a VPS and want to put it on port 443 with a proper TLS cert. Pick *Reverse proxy*, point at `http://127.0.0.1:3000`, flip SSL on, done. Nginx terminates TLS, your app stays plain HTTP behind it.
You bought a domain for a static landing page. Pick *Static site*, point root at `/var/www/your-site` and you get a working server-block with the right index files and a try_files fallback.
You are migrating an old domain to a new one. Pick *Redirect*, target `https://new.example.com$request_uri`, code `301`. Google updates the index, browsers cache the redirect, your old links keep working.
You want a subdomain for a blog. Pick *Subdomain*, prefix `blog`, base `example.com` and you get a complete `blog.example.com` server-block. Save under that exact filename to keep `sites-available/` tidy.
Your app cannot handle the load on one box. Pick *Load balancer*, paste three or four backend `address:port` lines, pick `least_conn` and nginx routes each request to the least busy one. Adding a server is one new line.
Your real-time chat is broken behind nginx because of WebSockets. Flip *Add WebSocket Upgrade headers* and nginx forwards `Upgrade` and `Connection` properly, with a 24h read timeout that survives long-lived connections.
You sit behind Cloudflare and all your logs say "172.x.x.x". Flip *Add Cloudflare real IP*, nginx rewrites `$remote_addr` from the `CF-Connecting-IP` header coming from Cloudflare ranges. Rate limits, fail2ban and audit logs work again.

Questions and answers

Nginx is a web server and a reverse proxy that listens on a port (usually 80 or 443), takes incoming HTTP requests, and decides what to do with each one. It can serve files from disk (like a static site), forward the request to another program running on the same machine (an app on `127.0.0.1:3000`, that is the reverse-proxy mode), redirect to another URL, or spread traffic across many backend servers. It is the standard front door for almost every Linux web stack and the thing that handles your SSL/TLS termination.

blocks pick which one to apply?

instead of just `index`?

Upgrade headers?

# 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; } }

What this builder gives you

How to use it

Pick a mode at the top: *Static site*, *Reverse proxy*, *Redirect*, *Subdomain* or *Load balancer*. Each mode shows only the fields that matter for it.

Type your domains in server_name. One domain per line. The first one is used as the certificate name.

Pick the listen port. 80 for plain HTTP, 443 for HTTPS, 8080 when an upstream proxy or Docker handles TLS.

For Reverse proxy: set proxy_pass to your backend, e.g. `http://127.0.0.1:3000`. Keep X-Forwarded- headers on so your app sees the real client IP.

For Load balancer: paste one `address:port` per line in *Backend servers* and pick an algorithm. Use upstream groups with `least_conn` for slow apps and `ip_hash` when you need sticky sessions.

Click Copy, paste into `/etc/nginx/sites-available/<your-file>.conf`, symlink to `sites-enabled`, run `sudo nginx -t` to validate syntax, then `sudo systemctl reload nginx`.

When this is useful

Seven situations where a ready-made server-block saves a lot of squinting at docs:

You deployed a Node, Python or Go app on a VPS and want to put it on port 443 with a proper TLS cert. Pick *Reverse proxy*, point at `http://127.0.0.1:3000`, flip SSL on, done. Nginx terminates TLS, your app stays plain HTTP behind it.
You bought a domain for a static landing page. Pick *Static site*, point root at `/var/www/your-site` and you get a working server-block with the right index files and a try_files fallback.
You are migrating an old domain to a new one. Pick *Redirect*, target `https://new.example.com$request_uri`, code `301`. Google updates the index, browsers cache the redirect, your old links keep working.
You want a subdomain for a blog. Pick *Subdomain*, prefix `blog`, base `example.com` and you get a complete `blog.example.com` server-block. Save under that exact filename to keep `sites-available/` tidy.
Your app cannot handle the load on one box. Pick *Load balancer*, paste three or four backend `address:port` lines, pick `least_conn` and nginx routes each request to the least busy one. Adding a server is one new line.
Your real-time chat is broken behind nginx because of WebSockets. Flip *Add WebSocket Upgrade headers* and nginx forwards `Upgrade` and `Connection` properly, with a 24h read timeout that survives long-lived connections.
You sit behind Cloudflare and all your logs say "172.x.x.x". Flip *Add Cloudflare real IP*, nginx rewrites `$remote_addr` from the `CF-Connecting-IP` header coming from Cloudflare ranges. Rate limits, fail2ban and audit logs work again.

Questions and answers

blocks pick which one to apply?

instead of just `index`?

Upgrade headers?

Nginx Config Snippet Builder

What this builder gives you

How to use it

When this is useful

Questions and answers

Related tools

SSH Config Builder

DNS Lookup

SSL Certificate Inspector

HTTP Headers Inspector

systemd Unit Builder

Nginx Config Snippet Builder

What this builder gives you

How to use it

When this is useful

Questions and answers

Related tools

SSH Config Builder

DNS Lookup

SSL Certificate Inspector

HTTP Headers Inspector

systemd Unit Builder