Nginx

Nginx - Basic

Page 2 of 2

Serving Static Files

The simplest thing Nginx can do is hand out files straight from disk. Two directives do most of the work: root, which sets the filesystem directory to serve from, and index, which sets the default file to return when a request doesn't name one.

server {
    listen 80;
    server_name static.example.com;

    root /var/www/static.example.com;   # base directory on disk
    index index.html;                    # default file for "/"

    location / {
        try_files $uri $uri/ =404;      # serve the file if it exists, else 404
    }
}

try_files is doing quiet but important work here. $uri is an Nginx variable holding the request path. Nginx tries that path as a file first, then as a directory ($uri/, which would pick up an index.html inside it), and if neither exists, it falls through to =404 and returns a clean 404 instead of some confusing default error. Without try_files, a request for a path that doesn't map to a real file would still error out, just with less predictable behavior.


Your First Reverse Proxy

Most of the time in a real DevOps job, Nginx isn't serving static files at all, it's standing in front of an application (a Node.js API, a Python service, whatever) and forwarding requests to it. The directive that does this is proxy_pass:

server {
    listen 80;
    server_name app.example.com;

    location / {
        proxy_pass http://127.0.0.1:3000;   # forward every matching request here
    }
}

That's a working reverse proxy in five lines. Every request that hits app.example.com on port 80 gets forwarded to whatever is listening on 127.0.0.1:3000, and Nginx relays the response back to the client. From the client's point of view, they're just talking to app.example.com, they have no idea there's a separate backend process behind it. This is the pattern behind almost every production web architecture: Nginx on the edge, application processes behind it, never exposed directly to the internet. There's more nuance to doing this well (which headers you need to forward so the backend isn't confused about who's really connecting), but that's a topic for the next tier up.


Testing and Reloading Config

Before you ever apply a config change, get in the habit of testing it first:

sudo nginx -t
# nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
# nginx: configuration file /etc/nginx/nginx.conf test is successful

nginx -t parses the entire config, including everything pulled in via include, and tells you if it's valid, without touching the running server at all. Once you know it's good, you apply it with:

sudo nginx -s reload

This tells the running master process to reread the config and reload it. Compare that to systemctl restart nginx, which stops and starts the whole service, briefly dropping the listening socket. A reload is the safer, near-zero-downtime way to apply changes, and nginx -t before every reload is one of those small habits that saves you from a very bad day. Pushing a typo'd config straight to reload without testing it first is a classic way to take a site down.


Where the Logs Live

Nginx keeps two logs, and they answer two different questions. The access log (/var/log/nginx/access.log by default) records every request that came in. The error log (/var/log/nginx/error.log) records problems: config issues, backend connection failures, and anything above a configured severity level.

opsquiz@devops-essentials
opsquiz@devops:~$ tail -f /var/log/nginx/access.log
203.0.113.7 - - [04/Sep/2026:10:15:32 +0000] "GET /api/health HTTP/1.1" 200 15 "-" "curl/8.4.0"

That one line breaks down as: the client IP (203.0.113.7), the timestamp, the request line (method, path, protocol version), the HTTP status code (200), the response body size in bytes (15), the referrer (- means none was sent), and the client's user agent string. tail -f (follow mode) is how you watch traffic live while debugging something. When something's actually broken, the error log is where you'll spend your time instead, and getting comfortable reading both is the first real Nginx skill worth building.

    Welcome to OpsQuiz!

    Real scenario-based DevOps questions, hands-on practice, and clear explanations for every answer.