Nginx for beginners: what you need to know

Why it exists

Your application can already answer requests. So why put something in front of it?

Several reasons:

• Secure connections. Easier to configure in one place than in every application.
• Serving files. A web server delivers images and stylesheets far more efficiently than an application.
• Several projects on one machine. It routes requests by domain.
• Rate limiting and protection against the simplest attacks.
• The application isn't exposed to the internet directly. That's safer.

How configuration is arranged

The configuration file consists of blocks. The main one describes a site: which domain we serve and what to do with requests.

A minimal version for an application listening on an internal port:

server {
    listen 80;
    server_name example.com;

    location / {
        proxy_pass http://127.0.0.1:8000;
        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;
    }
}

Reading that: listen on the plain web port, serve the named domain, pass everything to the application on its internal port.

The header lines matter: without them the application never learns the visitor's real address and concludes every request comes from the server itself.

Serving files directly

Images and other static assets are better served without involving the application:

location /static/ {
    alias /var/www/myapp/static/;
    expires 30d;
}

The second line tells browsers to cache for a month. It speeds up repeat visits noticeably.

Useful commands

Check the configuration before applying it:

nginx -t

Always do this before reloading. A configuration error on restart takes the site down; the check catches it beforehand.

Apply the configuration without dropping connections:

systemctl reload nginx

Watch the logs:

tail -f /var/log/nginx/error.log

Common mistakes

Forgetting the headers. The application sees every request as local, and address detection and secure-connection detection break.

Restarting without checking. One typo and the site is down.

A wrong path to files. A frequent cause of stylesheets not loading: the configured path doesn't match reality.

Not raising the upload size limit. The default is small, and image uploads fail with a cryptic error. It's a separate setting.

Configuring HTTPS but not the redirect. The site opens at both addresses and visitors land on the insecure one.

About matching order

The rules for choosing a location block aren't obvious: an exact address match outranks a prefix match, which in turn interacts with pattern rules.

The practical conclusion: when a rule doesn't fire, it's usually because a higher-priority one fired first. Read the whole file, not just your own rule.

Does a beginner need this

Not first. But if you deploy a project to your own server, you can't avoid it — and the fact that you configured a web server by hand distinguishes you at interview from people who clicked buttons in a control panel.