Nginx Config Reading
server_name, proxy_pass, SSL blocks, try_files, upstream — reading nginx configuration in plain English
Nginx config vocabulary
- server block — a virtual host; nginx matches the
Hostheader againstserver_nameto pick the right block - proxy_pass — forwards requests to a backend (reverse proxy pattern); nginx sits in front of the app
- listen 443 ssl — accepts HTTPS; requires
ssl_certificateandssl_certificate_key - try_files $uri $uri/ =404 — try exact file, then directory index, then return 404
- upstream + least_conn/weight — load balancing group; routes traffic to multiple backends
Question 0 of 5
Read this nginx config snippet. What is the purpose of the server_name directive?server {
listen 80;
server_name example.com www.example.com;
root /var/www/html;
}
- server block — equivalent to Apache's VirtualHost; one nginx config can have multiple server blocks for different domains
- server_name — nginx matches the incoming HTTP
Hostheader against this list; the first match wins - listen — the port (and optionally IP) to accept connections on
- root — the filesystem directory served as the document root
Host: example.com or Host: www.example.com header, this server block handles it and serves files from /var/www/html."What does proxy_pass http://localhost:3000 do in this nginx location block?location /api/ {
proxy_pass http://localhost:3000;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
}
- proxy_pass — tells nginx to forward the request to this upstream URL; nginx relays the response back to the client
- proxy_set_header — adds or overrides HTTP headers sent to the upstream; critical so the backend knows the real client IP and hostname
- X-Real-IP — the original client's IP address, passed because the backend only sees nginx's local IP otherwise
- $remote_addr — nginx variable holding the connecting client's IP
/api/ to a Node.js app on port 3000.Which block in this nginx config controls SSL/TLS settings?server {
listen 80;
server_name example.com;
return 301 https://$host$request_uri;
}
server {
listen 443 ssl;
server_name example.com;
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;
location / { root /var/www/html; }
}
- listen 443 ssl — listens on the HTTPS port with SSL/TLS handling enabled
- ssl_certificate — path to the public certificate chain (includes the domain cert + intermediates)
- ssl_certificate_key — path to the private key (keep this file permissions-restricted)
- ssl_protocols — whitelist of allowed TLS versions; disabling TLSv1.0/1.1 is a security best practice
return 301.What does this nginx location directive mean?location / {
try_files $uri $uri/ =404;
}
- $uri — the request path as a filesystem file (e.g.,
/about.html) - $uri/ — the request path as a directory; nginx will look for an index file (e.g.,
index.html) inside it - =404 — if neither exists, return an HTTP 404 response (the
=prefix means "return this status code")
try_files $uri $uri/ /index.html instead — falling back to the app's entry point so client-side routing can handle the URL.Read this nginx upstream block. What load balancing strategy does it use, and how many backend servers are configured?upstream app_backend {
least_conn;
server 10.0.0.1:3000;
server 10.0.0.2:3000;
server 10.0.0.3:3000 weight=2;
}
server {
location / {
proxy_pass http://app_backend;
}
}
- upstream block — defines a named group of backend servers for load balancing
- least_conn — sends each new request to the backend with the fewest active connections (vs. default round-robin)
- weight=N — a server with weight 2 receives twice the requests relative to weight 1 servers
- proxy_pass http://app_backend — references the upstream group by name
ip_hash (sticky sessions by client IP), hash $request_uri (cache-friendly URL-based routing).