Basic Configuration #

Before we go further and configure Nginx as a high-performance web server, a reliable reverse proxy, or a globally scaled load balancer, we must first understand its configuration language. Unlike traditional software configuration files, which generally take the form of simple flat key-value pairs, Nginx uses a declarative, block-based (context-based) configuration language that shares similarities with structured programming concepts. This syntax was specifically designed to express highly complex routing logic, header manipulation, and network data flow management efficiently.

In this introductory article, we’ll explore the unique philosophy behind Nginx’s configuration system, learn how Nginx processes configuration files asynchronously in memory, understand the request processing flow through systematic visual diagrams, and see the learning roadmap we’ll follow throughout this Basic Configuration section.

Nginx’s Configuration Philosophy: Centralization vs Distro (.htaccess) #

To appreciate why Nginx is so efficient, we need to compare Nginx’s configuration philosophy with the traditional approach popularized by the Apache HTTP Server. This fundamental difference isn’t just about syntax aesthetics — it’s a low-level architecture that significantly affects disk I/O performance and your server’s RAM utilization.

1. Apache’s Distributed Configuration Model (`.htaccess`) #

On traditional Apache servers, developers often use .htaccess files placed directly inside the application’s web root directory.

How it works: Every time an incoming request from a client accesses a file or URL, the Apache process must traverse the physical directory structure from the top folder down to the destination folder, looking for .htaccess files. If found, Apache opens the file from disk, parses its configuration rules in real time, then executes them for that request.
Performance impact: This approach triggers very high disk read overhead (I/O read overhead) for every single request. If a page loads 50 static files (images, CSS, JS), the server must scan and read configuration files dozens of times from physical storage, drastically slowing overall response time.

2. Nginx’s Centralized Configuration Model (`nginx.conf`) #

Nginx takes a completely opposite approach by eliminating support for dynamic directory-level configuration like .htaccess.

How it works: All Nginx configuration is centralized and loaded entirely into RAM when the Nginx master process first starts, or when we send a reload signal (systemctl reload nginx). Nginx compiles all rewrite rules, location matching, and variables into a very fast in-memory binary search tree data structure.
Performance impact: When a request arrives, the Nginx worker process matches the URL directly against the data structure already in RAM, without performing any disk reads for configuration files at all. This is the key to why Nginx can serve tens of thousands of requests per second with microsecond latency and minimal CPU consumption.

Configuration Context Hierarchy #

Nginx’s configuration language is organized hierarchically using blocks called Contexts. A context acts as a scope that groups configuration instructions (called Directives) with similar purposes. The relationships between contexts follow an inheritance principle, where configuration defined at upper levels is inherited by lower levels, unless explicitly redefined at the lower level.

Here’s a simple visual overview of the main context hierarchy forming the anatomy of your Nginx configuration:

main (Global Scope - OS & Network Driver Configuration)
├── events { } (Event Loop & Worker Socket Connection Settings)
├── http { } (Global HTTP Protocol & Web Services Configuration)
│   ├── upstream { } (Backend Cluster & Load Balancing Definitions)
│   ├── server { } (Virtual Host / Domain Name Configuration)
│   │   ├── location { } (URL Path Specification / Routing)
│   │   │   └── location { } (Nested Location for Special Protection)
│   │   └── location { } (Static File / Cache Handling)
│   └── server { } (Second Virtual Host)
└── stream { } (Transport-level TCP/UDP Load Balancing Configuration)

With this structure, we can set global security policies (like SSL protocols and extra headers) once in the http context, and let hundreds of server blocks beneath it inherit those policies automatically, without rewriting the same configuration over and over.

Request Processing Flow #

When a TCP data packet from a client browser arrives at your server’s network interface card (NIC), how does Nginx determine which configuration to execute? This process goes through a very strict, systematic matching flow. Nginx splits this matching into several stages: network port matching, domain name matching, URL path matching, and internal rewrite rule evaluation.

Let’s study Nginx’s decision logic flow through the following systematic flowchart:

flowchart TD
    Req["HTTP Request from Client Arrives"] --> MatchPort{"1. Find a Server Block <br> listening on the matching IP:Port"}
    
    MatchPort -->|"No Matching Port"| DropPort["Return Connection Error <br> (Connection Refused)"]
    
    MatchPort -->|"Several Blocks Found"| MatchHost{"2. Match the 'Host' Header <br> against 'server_name' directives"}
    
    MatchHost -->|"Exact Match"| TargetServer["Use the Selected Server Block"]
    MatchHost -->|"Wildcard Match (*.domain)"| TargetServer
    MatchHost -->|"Regex Match (~ expression)"| TargetServer
    MatchHost -->|"No Matching Domain"| DefaultServer{"3. Is there a <br> 'default_server' directive?"}
    
    DefaultServer -->|"default_server exists"| UseDefault["Use the default_server Server Block"]
    DefaultServer -->|"No default_server"| UseFirst["Use the First Server Block <br> loaded on that port"]
    
    TargetServer --> MatchLocation{"4. Match the URI Path <br> against 'location' blocks"}
    UseDefault --> MatchLocation
    UseFirst --> MatchLocation
    
    MatchLocation -->|"Exact Match (=)"| LocationAction["Execute the Directives in the Location Block"]
    MatchLocation -->|"Priority Prefix Match (^~)"| LocationAction
    MatchLocation -->|"Regex Match (~ / ~*)"| LocationAction
    MatchLocation -->|"Longest Prefix Fallback (/)"| LocationAction
    
    LocationAction --> TryFiles{"5. Is there a 'try_files' directive?"}
    
    TryFiles -->|"Yes"| CheckDisk{"Look for the file/folder on disk"}
    CheckDisk -->|"File exists"| ServeFile["Serve the File Directly"]
    CheckDisk -->|"Not found"| RewriteURL["Perform an internal redirect <br> to the fallback URI"]
    
    TryFiles -->|"No"| DirectAction["Execute the Main Handler <br> (proxy_pass / fastcgi_pass / return)"]
    
    RewriteURL --> MatchLocation
    ServeFile --> Respond["Send HTTP Response to the Client"]
    DirectAction --> Respond

Through the workflow above, we can see that Nginx never guesses what action to take. Every step is clearly defined by the combination of listen, server_name, location, and try_files directives we write in the configuration file.