Introduction to Nginx #

Before we write a single line of Nginx configuration, there’s a more fundamental question we need to answer: why should we care about the conceptual foundations of a web server? The answer is simple — the configuration we write every day reflects architectural decisions made two decades ago. Understanding those decisions transforms us from someone who merely memorizes configuration into someone who understands why that configuration exists. This page is designed to build that conceptual foundation, unpack the mystery behind Nginx’s extreme efficiency, and map out our learning journey through this book.

What We’ll Learn in This Section #

The Introduction section covers four main articles that complement each other and are designed to be read in sequence. Each article builds on the understanding from the previous one to provide a strong, holistic understanding.

flowchart TD
    A["1. What is Nginx?<br/>(Core Roles & Uses)"] -->|"Identify Nginx's core role"| B["2. History & Evolution<br/>(C10K Problem & Igor Sysoev)"]
    B -->|"Understand its architectural origins"| C["3. Nginx vs Apache<br/>(Event-Driven vs Process-Based)"]
    C -->|"Know when to choose which"| D["4. Event-Driven Architecture<br/>(Worker Processes & Event Loop)"]
    D -->|"Learn non-blocking mechanics"| E["READY: Section 02<br/>(Installation & Setup)"]

    style A stroke:#0288d1,stroke-width:2px
    style B stroke:#0288d1,stroke-width:2px
    style C stroke:#0288d1,stroke-width:2px
    style D stroke:#0288d1,stroke-width:2px
    style E stroke:#43a047,stroke-width:2px

After finishing this introduction section, we won’t just know how to use Nginx — we’ll understand the internal mechanics that let it handle tens of thousands of simultaneous connections with minimal memory consumption. This theoretical understanding will make it easier to debug complex configurations, optimize server performance under heavy load, and make sound system architecture decisions in production environments.

The Big Picture: Nginx in Modern Infrastructure #

In the topology of modern web infrastructure, Nginx holds a strategic position as the leading gatekeeper (edge server) that bridges the public internet with our backend application servers. Every time users around the world access our applications, their HTTP/HTTPS requests don’t directly touch the application code (such as Node.js, Python, Go, or PHP). Instead, those requests are received and processed first by Nginx. After Nginx performs validation, decryption, encryption, caching, or rate limiting, the requests are then forwarded to the backend server.

This front-line position gives Nginx extraordinary visibility and control over all data traffic. Nginx acts as a protective shield for our backend applications, which are usually vulnerable to direct connection loads, cyber attacks, or protocol exploits.

flowchart TD
    subgraph Klien["Clients & Internet"]
        U1["User A (Browser)"]
        U2["User B (Mobile App)"]
        U3["User C (API Client)"]
    end

    subgraph Gerbang["Edge Layer"]
        CDN["CDN & DNS (Cloudflare / CloudFront)"]
        NGX["Nginx Edge Proxy"]
    end

    subgraph Backend["Application Layer"]
        App1["App Server 1 (Node.js)"]
        App2["App Server 2 (Python WSGI)"]
        App3["App Server 3 (PHP-FPM)"]
    end

    subgraph Data["Storage Layer"]
        DB[("Database (PostgreSQL)")]
        Cache[("Cache (Redis)")]
    end

    U1 --> CDN
    U2 --> CDN
    U3 --> CDN
    CDN -->|"Filtered & Encrypted Traffic"| NGX

    NGX -->|"/api/v1/users (Port 3000)"| App1
    NGX -->|"/api/v1/orders (Port 8000)"| App2
    NGX -->|"/blog (FastCGI Socket)"| App3

    App1 --> DB
    App2 --> DB
    App3 --> Cache
    App1 --> Cache

    style NGX stroke:#0288d1,stroke-width:3px
    style CDN stroke:#ffb300,stroke-width:2px
    style DB stroke:#43a047,stroke-width:2px
    style Cache stroke:#e53935,stroke-width:2px

By placing Nginx in this position, we can centralize security management, SSL/TLS certificates, and traffic optimization in one place, so our application servers can focus entirely on business logic without being burdened by network protocol management overhead.

Why Conceptual Foundations Matter More Than Syntax #

Many beginner developers jump straight to copy-pasting configuration from Stack Overflow or third-party documentation without understanding what each line of code does. This syntax-memorization approach is very dangerous in production environments. Nginx configuration isn’t like ordinary application code that immediately triggers a compilation error when wrong; logical configuration errors in Nginx (for example, placing a directive in the wrong context) can cause critical security holes or memory leaks without triggering any error when the server starts.

Let’s compare two approaches to using Nginx:

Type A — Configuration Memorization Approach:
  - Copying configuration raw from search engines or AI without verification.
  - Modifying domains and document paths by trial-and-error.
  - Running a reload and hoping everything works.
  - When an error occurs (e.g., HTTP 502 or 504): confusion and endlessly copying other configs.
  - Not understanding how directive inheritance works in Nginx.
  - Unable to diagnose performance bottlenecks at the OS kernel level.

Type B — Foundation Understanding Approach (Our Goal):
  - Understanding the logical reasoning behind every directive in a configuration file.
  - Knowing the context scope structure precisely (main, events, http, server, location).
  - When an error occurs: immediately checking access/error logs and pinpointing the architectural flaw.
  - Able to tune OS parameters (such as worker_connections, file descriptors, sysctl backlog).
  - Understanding the request processing flow from header reading to response delivery.
  - Writing clean, modular, secure, and maintainable configuration.

This book is written with the goal of shaping readers into Type B. We’ll learn abstract concepts first, visualize them with comprehensive data flow diagrams, and only then translate them into optimal Nginx configuration syntax.

Nginx Is Not One Thing — It Is Many Things #

One of the most common misconceptions among software engineers is treating Nginx as just an ordinary “web server” like the old Apache HTTP Server. In fact, Nginx is a versatile traffic processing platform that can be configured to play various critical roles in our system architecture.

Here are the five main roles Nginx can play, either standalone or simultaneously in a single server instance:

1. Nginx as a Web Server #

Nginx can serve static file requests (such as HTML files, CSS stylesheets, JavaScript scripts, images, and videos) directly from local storage (disk) to the user’s browser at incredible speed. This speed is achieved thanks to non-blocking I/O features and low-level OS system calls like sendfile() that avoid processing data in user space.

flowchart LR
    Klien["User's Browser"] -->|"Request: /index.html"| NGX["Nginx Web Server"]
    NGX -->|"System Call: sendfile()"| Disk[("Storage Disk")]
    Disk -->|"Direct Kernel Memory Transfer"| Klien

    style NGX stroke:#0288d1,stroke-width:2px
    style Disk stroke:#43a047,stroke-width:2px

Use Cases: Static portfolio websites, SPA applications (Single Page Applications like React, Vue, or Angular after the production build process), CDN origin servers, and static media asset hosting.

2. Nginx as a Reverse Proxy #

As a reverse proxy, Nginx stands in front of one or more backend application servers. Nginx receives requests from external clients and forwards (proxies) them to internal backend servers (such as Node.js running on port 3000, or Python Gunicorn on port 8000). After the backend processes the request and provides a response, Nginx sends that response back to the client.

flowchart LR
    Klien["External Client"] -->|"HTTP / HTTPS (Port 80/443)"| NGX["Nginx Reverse Proxy"]
    NGX -->|"HTTP (Local Port / Socket)"| App["Application Server (NodeJS/Go)"]
    App -->|Response| NGX
    NGX -->|Response| Klien

    style NGX stroke:#0288d1,stroke-width:2px
    style App stroke:#8e24aa,stroke-width:2px

Use Cases: Securing backend application servers from direct public internet exposure, hiding internal server port architecture, and handling response buffering from slow backend servers.

3. Nginx as a Load Balancer #

When traffic to our application spikes sharply, a single backend server instance can’t handle the entire workload. Nginx can be configured as a load balancer to distribute incoming requests evenly across a cluster of backend servers using various algorithms (such as Round Robin, Weighted Round Robin, Least Connections, or IP Hash).

flowchart LR
    Klien["Incoming Traffic"] --> NGX["Nginx Load Balancer"]
    NGX -->|"Round Robin / IP Hash"| B1["Backend Server A"]
    NGX -->|"Round Robin / IP Hash"| B2["Backend Server B"]
    NGX -->|"Round Robin / IP Hash"| B3["Backend Server C"]

    style NGX stroke:#0288d1,stroke-width:3px
    style B1 stroke:#8e24aa,stroke-width:2px
    style B2 stroke:#8e24aa,stroke-width:2px
    style B3 stroke:#8e24aa,stroke-width:2px

Use Cases: Horizontal scaling of web applications with high availability, avoiding single points of failure through dead-server detection (passive health check).

4. Nginx as an API Gateway #

In microservices architectures, Nginx can act as a single API Gateway managing request routing based on URL paths to various internal microservices. Nginx can also centralize common features such as API key authentication, per-client rate limiting, and CORS header manipulation.

flowchart LR
    Klien["API Client"] -->|"endpoint: /api/*"| NGX["Nginx API Gateway"]
    NGX -->|"/api/users"| US["User Microservice"]
    NGX -->|"/api/billing"| BS["Billing Microservice"]
    NGX -->|"/api/products"| PS["Product Microservice"]

    style NGX stroke:#0288d1,stroke-width:2px
    style US stroke:#e53935,stroke-width:2px
    style BS stroke:#e53935,stroke-width:2px
    style PS stroke:#e53935,stroke-width:2px

Use Cases: Microservices-based infrastructure, unifying a single API domain for web and mobile application consumption, centralized security for API endpoints.

5. Nginx as an SSL/TLS Terminator #

The SSL/TLS (HTTPS) encryption and decryption process requires extremely CPU-intensive computation (cryptographic overhead). By centralizing SSL configuration at Nginx (SSL Termination), Nginx handles all cryptographic HTTPS handshakes with internet clients, then forwards the safely decrypted traffic over plain HTTP to internal backend servers.

flowchart LR
    Klien["Client (Internet)"] -->|"HTTPS (Encrypted Traffic)"| NGX["Nginx SSL Terminator"]
    NGX -->|"HTTP (Plain/Decrypted Traffic)"| App["Backend Server (Internal Network)"]
    App -->|"HTTP"| NGX
    NGX -->|"HTTPS (Re-encrypted)"| Klien

    style NGX stroke:#0288d1,stroke-width:2px
    style App stroke:#8e24aa,stroke-width:2px

Use Cases: All modern web deployments that need HTTPS security standards without burdening the CPU resources of backend language runtimes (like PHP or Node.js).

Nginx’s Design Philosophy: Three Core Principles #

Nginx’s architecture is based on three main principles designed by its creator, Igor Sysoev, to overcome the performance limitations faced by older-generation web servers (like Apache HTTP Server).

1. Efficiency Above All #

Nginx is designed to consume as little hardware resources as possible. To achieve this extreme efficiency, Nginx avoids creating a new thread or process for every incoming connection. Nginx uses a non-blocking I/O event-driven architecture that leverages efficient kernel-level I/O multiplexing mechanisms (such as epoll on Linux, or kqueue on BSD/macOS).

In this event-driven model, a single worker process can handle thousands of connections simultaneously with one event loop. This is very different from the old Apache model, which requires a separate thread/process for every single connection — prone to memory bottlenecks due to CPU context switching.

2. Predictable Resource Consumption Under Load #

One of Nginx’s main advantages in production environments is its remarkable stability during traffic spikes. Nginx’s memory consumption is linear and very flat, even when the number of connections grows from 100 to 10,000 concurrent connections.

+-----------------------------------------------------------+
| ESTIMATED MEMORY ALLOCATION COMPARISON UNDER LOAD        |
|                                                           |
| Connections:  100        1,000       5,000      10,000   |
|                                                           |
| Apache (Fork):  ~50 MB     ~500 MB     ~2.5 GB     OOM/Crash|
| Nginx (Event):  ~10 MB     ~15 MB      ~25 MB      ~35 MB |
+-----------------------------------------------------------+

Because Nginx worker processes are allocated statically according to the number of physical CPU cores at startup, there’s no uncontrolled dynamic memory allocation overhead when the server receives extremely high traffic loads.

3. Configuration as Code #

Nginx’s configuration syntax is designed to be declarative, logical, and clean. Nginx configuration files can be read easily like ordinary program code, stored in Git repositories (version control), automatically syntax-tested with the nginx -t command, and reloaded without downtime via nginx -s reload. This makes integration with modern DevOps automation pipelines (like Ansible, Terraform, Docker, and Kubernetes) easy.

The Nginx Ecosystem: More Than a Single Binary #

When we install Nginx, we’re not just installing a web server — we’re entering a vast, mature software ecosystem. Some of the main variants of the Nginx ecosystem we often encounter in the industry include:

flowchart TD
    Core["Nginx Open Source (Core)"] -->|"Enterprise Features"| Plus["Nginx Plus (Commercial)"]
    Core -->|"Lua / LuaJIT Integration"| OR["OpenResty (APIs & WAF)"]
    Core -->|"Kubernetes Ingress"| IC["Nginx Ingress Controller"]

    style Core stroke:#0288d1,stroke-width:3px
    style Plus stroke:#d32f2f,stroke-width:2px
    style OR stroke:#7b1fa2,stroke-width:2px
    style IC stroke:#388e3c,stroke-width:2px

Nginx Open Source (Core): The free, open-source version available in standard Linux distro repositories. This is the main focus of our learning in this book.
Nginx Plus: The paid commercial version aimed at large corporate needs. This variant includes additional advanced features like active health checks, web-based real-time monitoring dashboards, built-in JWT authentication, and dynamic upstream server configuration without needing a server reload.
OpenResty: A very popular Nginx distribution for building high-performance API Gateways. OpenResty combines the Nginx core with LuaJIT (Lua Just-In-Time Compiler), allowing us to write request handling logic (like database validation, JWT token checks, header manipulation, or security firewalls) directly inside Nginx configuration files using the Lua programming language.
Nginx Ingress Controller: A crucial component in the Kubernetes ecosystem that acts as a bridge, translating Kubernetes Ingress resource objects into dynamic Nginx routing configuration files in real time.

Prerequisites for Following This Book #

This book is structured to be understood by developers with various levels of experience. However, to get the most out of the tutorials and practical exercises presented, we assume you have basic knowledge of:

Basic Linux Navigation: Comfortable using the Linux terminal, understanding basic commands (like cd, ls, mkdir, cp, mv), able to use terminal-based text editors (like nano or vim), and understanding how to run commands with administrator privileges (sudo).
Basic Networking Concepts: Understanding the concept of ports (for example, the default HTTP port is 80, HTTPS is 443), IP addresses (public vs private), how DNS (Domain Name System) mapping works, and TCP/IP protocols in general.
The HTTP Protocol: Understanding the differences between HTTP request methods (like GET, POST, PUT, DELETE), request/response header structure, and the meaning of HTTP Status Codes (e.g., 200 OK, 301 Redirect, 404 Not Found, 502 Bad Gateway).

We do not need advanced system administration experience (advanced sysadmin) or prior knowledge of the Apache web server to follow this book. We’ll build all these concepts from the ground up, step by step.

Nginx Versions Used in This Book #

This book is written and tested using Nginx 1.24.x (Stable) and Nginx 1.25.x (Mainline) running on Ubuntu Server 22.04 LTS. However, about 95% of the material and configuration examples in this book remain valid and applicable to Nginx 1.18 and above.

# Command to check the installed Nginx version
nginx -v
# Example output: nginx version: nginx/1.24.0

# Command to check the detailed version along with module compile options
nginx -V

We’ll focus on using stable built-in modules to ensure broad compatibility across our various production servers.

How to Read This Book #

This book is designed to be read linearly from start to finish to build a complete understanding structure. However, you can adjust your reading method based on your experience background:

For Complete Beginners: Read in order without skipping any chapter. The concepts built in Sections 01–03 are the key to understanding the advanced configuration in later sections.
For Experienced Developers: You can skim through Sections 01 and 02, then focus directly on Section 03 (Basic Configuration) and specific chapters like Reverse Proxy (Section 05), Load Balancing (Section 06), SSL/TLS (Section 07), Security (Section 08), and Performance Optimization (Section 10).
For Quick Reference: At the end of every article page, there’s a Summary box ({{< hint tip >}}) presenting the article’s key points compactly, helping you refresh your memory in less than a minute.

Recommended Practice Environments #

To practice the configurations in this book, we need a Linux server environment. Here are several practice environment options you can set up:

Option 1: VPS / Cloud Instance (Highly Recommended): Rent a cheap virtual server from a cloud provider (like DigitalOcean, AWS EC2, Linode, Google Cloud, or Vultr) with Ubuntu Server 22.04 LTS and minimal specs (1 vCPU, 1 GB RAM). This option is recommended because it provides a realistic production environment simulation, including having a public IP address for testing Let’s Encrypt SSL certificates.
Option 2: Local Virtual Machine: Use virtualization software like Oracle VirtualBox or VMware Player on your local computer, then install Ubuntu Server inside it.
Option 3: Windows Subsystem for Linux (WSL2): For Windows users, you can use WSL2 with the Ubuntu distro. This is very fast for local testing, although there are some differences in loopback network handling.
Option 4: Docker Container (Quick Experiments): Run the official Nginx container using Docker commands in your local terminal:
```
# Run a test Nginx container on local port 80
docker run -d --name nginx-lokal -p 80:80 nginx:1.24-alpine
```

The Configuration File Structure We’ll Build #

Throughout this book, we’ll gradually build a clean, modular, maintainable production server configuration structure. We’ll avoid piling hundreds of lines of configuration into a single file. As an overview, here’s the final configuration directory structure we’ll create:

/etc/nginx/
├── nginx.conf                    # Global configuration (main process & event)
├── conf.d/
│   ├── security.conf             # Global security parameter settings
│   ├── gzip.conf                 # Global response compression configuration
│   └── rate-limit.conf           # Global rate limit zone definitions
├── sites-available/
│   ├── app_utama.conf            # Main web application virtual host
│   └── api_backend.conf          # Backend API routing virtual host
├── sites-enabled/
│   └── app_utama.conf -> ../sites-available/app_utama.conf
└── snippets/
    ├── ssl-params.conf           # SSL/TLS configuration parameter collection
    ├── proxy-headers.conf        # Standard HTTP headers forwarded to backends
    └── security-headers.conf     # HTTP security headers collection (HSTS, CSP, etc.)

This modular structure makes it easier to scale, manage dozens of website domains on one server, and minimize configuration code duplication.

What Makes Nginx Configuration “Good” #

An Nginx configuration file is considered high quality if it satisfies the following four main dimensions:

Correct: The configuration performs its job precisely without side effects. For example, a small error in writing the slash / on a location directive can fatally break static file routing mapping without triggering a syntax error.
Secure: Follows the strictest industry security standards. This includes hiding the Nginx version (server_tokens off), setting a maximum client request body upload size, enabling HTTP security headers, and closing old HTTP protocol exploit holes.
Efficient: Optimizes hardware usage. Enabling compression features, leveraging client-side caching via Cache-Control headers, using keepalive connections to upstream backend servers, and enabling open file cache.
Maintainable: Configuration written neatly using snippet encapsulation techniques for repeated parts, clear server block domain naming, and explanatory comments on special logic lines.

Let’s look at a real comparison between a high-quality configuration and a poor one:

# ANTI-PATTERN: Messy, insecure, and inefficient configuration
server {
    listen 80;
    server_name example.com;

    # ✗ ROOT PLACED INSIDE LOCATION (Inefficient & vulnerable to security bypass)
    location / {
        root /var/www/html;
        index index.html;
    }

    # ✗ NO CACHE SETTINGS FOR STATIC ASSETS (Wasting bandwidth)
    location ~* \.(jpg|jpeg|png|gif|css|js)$ {
        # serving images without cache control
    }
}

# CORRECT: Modular, secure, efficient, and maintainable configuration
server {
    listen 80;
    server_name example.com;
    
    # ✓ ROOT AT THE SERVER BLOCK LEVEL (Global inheritance to all sub-locations)
    root /var/www/html;
    index index.html;

    # ✓ GLOBAL SECURITY PARAMETERS
    server_tokens off;             # Hide the Nginx version from the Server header
    client_max_body_size 10m;      # Limit maximum file upload to 10 Megabytes

    # ✓ EFFICIENT: Aggressive cache settings for client static assets
    location ~* \.(jpg|jpeg|png|gif|css|js)$ {
        expires 30d;
        add_header Cache-Control "public, no-transform";
    }

    # ✓ MAINTAINABLE: Main routing mapping
    location / {
        try_files $uri $uri/ =404;
    }
}

Throughout this book, we’ll always design and practice configuration that adheres to high-quality writing standards like the examples above.

Nginx in the Real World: Numbers and Facts #

Before we start learning, it’s worth understanding how widely Nginx is used. This isn’t just popularity — these numbers reflect an industry trust built over two decades.

Usage Metric	Market Share & Volume (Estimated 2024)
All Websites	~34% of all identified sites
Top 1 Million Largest Websites	~60%+ market share
Docker Hub Pulls	1+ Billion official image downloads
Kubernetes Ingress	Nginx Ingress Controller is the world’s most popular

Trusted by Tech Giants: #

Netflix: Streams compressed video content at petabyte bandwidth using Nginx edge servers.
GitHub: Manages repository code requests and static pages for millions of developers worldwide.
Cloudflare: Operates their global CDN network on massively modified Nginx-based edge servers (nginx-cloudflare).
DuckDuckGo: This privacy-focused search engine secures user requests using Nginx Edge.

Nginx vs Modern Competitors: A Brief Overview #

The modern web server and reverse proxy ecosystem offers various alternatives. Here’s a concise comparison of Nginx with its main competitors:

Nginx vs Caddy #

Caddy (written in Go) offers built-in automatic HTTPS via Let’s Encrypt and a more developer-friendly syntax.

Caddyfile:

example.com {
    reverse_proxy localhost:3000
}

Nginx Equivalent: Requires manual port 80/443 server block setup and certbot integration, but gives much more precise performance control for high-compute scenarios.

Nginx vs Traefik #

Traefik is designed specifically for container ecosystems with dynamic auto-discovery configuration.

Traefik Docker Label:

labels:
  - "traefik.enable=true"
  - "traefik.http.routers.myapp.rule=Host(`example.com`)"

Nginx: Excels at handling static traffic loads, cache optimization, and stability in traditional non-container server environments.

Nginx vs HAProxy & Envoy #

HAProxy: A pure TCP/HTTP level load balancing specialist with slightly faster raw performance, but cannot serve static files from disk like Nginx.
Envoy: A modern layer-7 proxy highly optimized for advanced Kubernetes service mesh architectures, but with a very steep configuration learning curve compared to Nginx’s declarative syntax.

flowchart TD
    Start{"Choose a Web Server/Proxy"}
    
    Start -->|"Shared Hosting / Legacy CMS (.htaccess)"| Apache["Apache HTTP Server"]
    Start -->|"Zero-Config Local SSL / Small Projects"| Caddy["Caddy Server"]
    Start -->|"Dynamic Kubernetes / Docker Swarm Containers"| Traefik["Traefik Proxy"]
    Start -->|"Pure High-Performance TCP Load Balancing"| HAProxy["HAProxy"]
    Start -->|"Complex Microservices & Service Mesh"| Envoy["Envoy Proxy"]
    Start -->|"Universal Web Server, Proxy, SSL & Cache"| Nginx["Nginx Open Source"]

    style Nginx stroke:#0288d1,stroke-width:3px
    style Apache stroke:#777,stroke-width:1px
    style Caddy stroke:#777,stroke-width:1px
    style Traefik stroke:#777,stroke-width:1px
    style HAProxy stroke:#777,stroke-width:1px
    style Envoy stroke:#777,stroke-width:1px

The Lifecycle of a Request in Nginx #

To give a more concrete picture, here’s the complete journey of an HTTP/HTTPS request passing through an Nginx worker process until it’s sent back to the client:

sequenceDiagram
    autonumber
    participant Klien as Client Browser
    participant OS as OS Kernel (epoll)
    participant NGX as Nginx Worker
    participant App as Backend (Node/PHP)
    
    Klien->>OS: TCP SYN (Request Port 443)
    OS->>NGX: Event Trigger: accept()
    Note over NGX: Allocate memory from Request Pool
    NGX->>Klien: TLS Handshake & Cipher Negotiation
    Klien->>NGX: HTTP Request (GET /api/users)
    Note over NGX: Match server_name & location
    alt Serve Static File
        NGX->>OS: sendfile() kernel system call
        OS->>Klien: Send file directly from disk
    else Forward to Backend
        NGX->>App: proxy_pass HTTP (Internal Connection)
        App->>NGX: HTTP Response (JSON/HTML)
        NGX->>Klien: Encrypt & Send Response
    end
    Note over NGX: Log to access.log & Free the Pool

Preview: What’s in the Following Sections #

Our journey through this book is designed systematically from beginner to expert:

Section 02 — Installation: Installing Nginx on Ubuntu, CentOS, Docker, and manual compilation from source code.
Section 03 — Basic Configuration: Understanding directive inheritance concepts, context scopes, server blocks, location blocks, and variable usage.
Section 04 — Web Server: Serving static files optimally, alias vs root, autoindex, and custom error pages.
Section 05 — Reverse Proxy: Forwarding requests with proxy_pass, manipulating proxy headers, buffering, and caching.
Section 06 — Load Balancer: Distributing traffic with Round Robin, Least Conn, IP Hash, and server health checks.
Section 07 — SSL/TLS: Enabling HTTPS, Let’s Encrypt Certbot integration, TLS session resumption, and HTTP/2.
Section 08 — Security: Securing the server with basic authentication, rate limiting, IP restriction, DoS protection, and security headers.
Section 09 — Logging: Custom log settings, automatic log rotation, and log performance analysis.
Section 10 — Performance: Worker process tuning, gzip compression, keepalive upstream pooling, and open file cache.
Section 11 — Modules: Adding dynamic modules, an introduction to OpenResty, and basic Lua scripting.
Section 12 — Use Cases: Production-ready configuration templates for PHP-FPM, Node.js, Python Gunicorn, WebSocket, and SPA runtimes.
Section 13 — Troubleshooting: Techniques for analyzing error logs, simulating common errors (502, 504), diagnostic tools, and audit checklists.

Building the Right Mental Model #

Before reading the first article, here’s one mental model that helps a lot: imagine Nginx as a very smart gatekeeper in front of a building complex (our application servers).

This gatekeeper:

Checks every guest (request) arriving at the main gate.
Directs guests to the right building based on the identity or destination listed on the invitation (server_name and location).
Rejects suspicious guests or those arriving too quickly in succession (rate limiting).
Serves guests directly if they’re only asking for general information brochures (static files) without needing to call anyone inside the application building.
Records the name & time of every guest’s visit in the log guestbook (access_log).
Can chat with thousands of guests at once without getting flustered, because it never stands still waiting for one guest to finish their business (non-blocking event loop).

Carry this gatekeeper mental model with you as you study the following chapters. It will make complicated technical terms much more intuitive.

Happy learning — let’s start with the most fundamental question: what exactly is Nginx?