Nginx server block
A server block is the unit Nginx uses to decide which site answers a request, combining the listening port, the host name, and what to do with each path inside it, whether serving files, forwarding to an application, or processing PHP.
Any route that does not match a real file gets the same index.html with a 200 status, leaving the client-side router to decide what to show.
The X-Forwarded-Proto header is what lets the application behind the proxy know whether the original connection was https, even with Nginx delivering HTTP internally.
The regular expression matches the file extension case-insensitively, applying a one-year cache only to those file types, never to HTML.
The standard is to save it in /etc/nginx/sites-available/your-domain and create a symlink in /etc/nginx/sites-enabled. Then run nginx -t to validate the syntax and systemctl reload nginx (or service nginx reload) to apply without dropping connections.
In most cases it is because the files pointed to by `ssl_certificate` and `ssl_certificate_key` do not exist on the server yet. Nginx validates those paths when loading the config, so the certificate needs to be issued first (with Certbot, for example) before the 443 block can be used.
The static one ends with `=404`, returning a real error when the file does not exist; the SPA one falls back to `/index.html`, so nonexistent routes load the same page with a 200 status instead of a 404, because the client-side JavaScript is what decides whether the route is valid.
Yes, each `listen` directive covers one address family only; that is why the generated block always carries a pair of directives, `listen 443 ssl` for IPv4 and `listen [::]:443 ssl` for IPv6, repeated on port 80 too when the HTTP redirect is active.
The `proxy_set_header Upgrade $http_upgrade` and `Connection "upgrade"` lines are what let a WebSocket connection survive the proxy, switching from plain HTTP to the upgrade protocol without Nginx dropping the connection midway.
# Server block gerado por jkit.tools
# Redireciona HTTP -> HTTPS
server {
listen 80;
listen [::]:80;
server_name example.com www.example.com;
return 301 https://$host$request_uri;
}
server {
listen 443 ssl http2;
listen [::]:443 ssl http2;
server_name example.com www.example.com;
root /var/www/example.com/public;
index index.html index.htm;
# TLS
ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
ssl_protocols TLSv1.2 TLSv1.3;
ssl_prefer_server_ciphers on;
client_max_body_size 16m;
# Cabeçalhos de segurança
add_header X-Content-Type-Options "nosniff" always;
add_header X-Frame-Options "SAMEORIGIN" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
# Compressão
gzip on;
gzip_vary on;
gzip_types text/plain text/css application/javascript application/json image/svg+xml;
location / {
try_files $uri $uri/ =404;
}
# Cache de assets estáticos
location ~* \.(?:css|js|jpg|jpeg|png|gif|ico|svg|woff2?)$ {
expires 1y;
add_header Cache-Control "public, immutable";
}
}
The configuration is generated entirely in your browser from the options. No data is sent to any server.