SadServers
  • Scenarios
  • Labs
    All Labs Linux & Bash Web Servers Databases Data Processing Docker Kubernetes CI/CD Infrastructure as Code Tooling / Applications
  • Dashboard
  • Solutions
    For Individuals For Businesses
  • Ranking
  • Newsletter
  • Documentation
    FAQ Support Pro Accounts Pro+ Accounts Business Accounts Gift API CLI/TUI Privacy Troubleshooting Interviews
  • Blog
  • Pricing
  • Gift
    Gift Purchase Gift Redeem
  • About
Log In - Sign Up
  1. Labs
  2. Nginx
  3. Guide

Guide

Concepts and learning path

Troubleshooting

Failure modes and fixes

Cheatsheet

Commands to keep handy

Nginx guide

What Nginx does in production

Nginx handles HTTP/HTTPS connections with an event-driven architecture that scales well under concurrency. It serves files from disk, reverse-proxies to app servers (Gunicorn, uWSGI, Node), and can load-balance across upstreams. TLS termination, gzip compression, caching, and rate limiting are configured in plain-text config files — no modules to compile for most use cases.

How a request is handled

When a client connects, the typical workflow is:

  1. TCP accept — a worker process accepts the connection on a listen socket
  2. TLS handshake — if HTTPS, the certificate is selected by SNI hostname
  3. Server block match — Nginx picks a server { } block using listen, server_name, and default-server flags
  4. Location match — within the server block, the best-matching location handles the URI (prefix, exact =, regex ~)
  5. Handler — static file (root / try_files), proxy (proxy_pass), or redirect (return)
  6. Response — logged to access_log; errors go to error_log

If no server_name matches, Nginx uses the default server for that port — usually the first server block defined.

Configuration layout

  • Debian/Ubuntu — /etc/nginx/nginx.conf includes sites-enabled/; enable sites with symlinks from sites-available/
  • RHEL/CentOS/Rocky — /etc/nginx/nginx.conf includes conf.d/*.conf
  • Snippets — shared fragments in /etc/nginx/snippets/ (SSL params, proxy headers)

Test before reload: nginx -t. Apply: systemctl reload nginx.

Key directives to know

  • server_name — hostnames this server block responds to
  • root / alias — filesystem path for static files (alias replaces the matched location path)
  • proxy_pass — upstream URL for reverse proxying
  • upstream — named backend pool with load-balancing
  • try_files — try paths in order; common pattern for SPAs
  • client_max_body_size — upload limit (413 if exceeded)
  • include — pull in other config files

Location matching priority

Nginx chooses the most specific match: exact = beats prefix (longest wins), then regex in definition order, then general prefix. A common mistake is a broad location / catching requests meant for location /api/ — prefix length and ordering matter.

Learning resources

  • Nginx documentation — nginx.org/en/docs (official reference)
  • Server names — nginx.org/en/docs/http/server_names (how server blocks are selected)
  • ngx_http_proxy_module — nginx.org/en/docs/http/ngx_http_proxy_module (reverse proxy directives)
  • Beginner's guide — nginx.org/en/docs/beginners_guide (configuration walkthrough)

Practice scenarios

Hands-on Nginx scenarios on live Linux VMs: nginx

Troubleshooting →
SadServersSadServers

Real-world Linux and DevOps scenarios for hands-on learning and technical assessment.

Uptime Robot ratio (30 days)
Product
  • Scenarios
  • For Individuals
  • For Businesses
  • Pricing
Resources
  • FAQ
  • Blog
  • Newsletter
Company
  • About Us
  • Support
  • Privacy Policy
  • Terms of Service
  • Contact
Connect With Us
info@sadservers.com

Made in Canada 🇨🇦
Updated: 2026-06-13 16:06 UTC – 2d2950a