Contexts (main, events, http, server, location) in Nginx - Step-by-Step Execution

Process Flow - Contexts (main, events, http, server, location)

Start: nginx.conf file

↓

main context

↓

events context

↓

http context

↓

server context

↓

location context

↓

Request handling

↓

Response sent

nginx configuration is structured in nested contexts: main, events, http, server, and location. Each context controls different parts of nginx behavior.

Execution Sample

Nginx

worker_processes  1;
events {
  worker_connections  1024;
}
http {
  server {
    location / {
      root /var/www/html;
    }
  }
}

This config sets one worker process, limits connections, and serves files from /var/www/html for requests to root location.

Process Table

Step	Context Entered	Directive Processed	Effect	Next Context
1	main	worker_processes 1;	Sets number of worker processes to 1	events
2	events	worker_connections 1024;	Limits max connections per worker to 1024	http
3	http	server { ... }	Defines HTTP server block	server
4	server	location / { ... }	Defines location block for root path	location
5	location	root /var/www/html;	Sets document root for requests	Request handling
6	Request handling	Request to /index.html	Serves file /var/www/html/index.html	Response sent
7	-	-	-	End of processing

💡 All contexts processed and request served, nginx completes handling

Status Tracker

Variable	Start	After Step 1	After Step 2	After Step 3	After Step 4	After Step 5	Final
worker_processes	default (auto)	1	1	1	1	1	1
worker_connections	default (1024)	1024	1024	1024	1024	1024	1024
server_blocks	none	none	none	1 server block	1 server block	1 server block	1 server block
location_blocks	none	none	none	none	1 location block	1 location block	1 location block
document_root	none	none	none	none	none	/var/www/html	/var/www/html

Key Moments - 3 Insights

Why can't we put 'worker_connections' inside the 'http' context?

'worker_connections' must be inside the 'events' context as shown in step 2 of the execution_table. Placing it elsewhere causes nginx to reject the config.

What happens if we put 'root' directive outside the 'location' context?

'root' is valid inside 'http', 'server', or 'location' contexts, but placing it inside 'location' (step 5) scopes it specifically to that path. Outside location, it applies more broadly.

How does nginx decide which 'location' block to use?

Nginx matches the request URI against 'location' blocks defined in the 'server' context (step 4). The best match is chosen to serve the request.

Visual Quiz - 3 Questions

Look at the execution_table at step 3. What does entering the 'http' context allow you to configure?

A Define server blocks to handle HTTP requests

B Set worker process numbers

C Limit worker connections

D Serve static files directly

💡 Hint

Check the 'Directive Processed' and 'Effect' columns at step 3 in execution_table

At which step does nginx set the document root for serving files?

A Step 2

B Step 4

C Step 5

D Step 6

💡 Hint

Look at the 'Directive Processed' column for 'root /var/www/html;' in execution_table

If you increase 'worker_connections' to 2048, which variable_tracker value changes?

A worker_processes

B worker_connections

C server_blocks

D document_root

💡 Hint

Check the 'worker_connections' row in variable_tracker for changes

Concept Snapshot

nginx config uses nested contexts:
- main: global settings like worker_processes
- events: connection limits
- http: HTTP server configs
- server: virtual hosts
- location: URL path handling
Directives must be in correct context to work.

Full Transcript

Nginx configuration is organized in nested contexts. The main context sets global options like worker_processes. The events context controls connection limits such as worker_connections. The http context groups HTTP server settings. Inside http, server contexts define virtual hosts. Each server can have multiple location contexts to handle specific URL paths. Directives must be placed in the correct context to take effect. For example, worker_connections belongs in events, while root belongs in location or server. When nginx starts, it reads the config top-down entering each context and applying directives. When a request arrives, nginx matches it to a server and location context to serve content accordingly.

Practice

1. Which nginx context is used to define global settings that affect the entire nginx server?

easy

A. main

B. http

C. server

D. location

Solution

1. Step 1: Understand nginx context scopes

   The main context is the top-level context for global settings.

2. Step 2: Differentiate other contexts

   The http context is for HTTP-specific settings, server for virtual hosts, and location for URL matching.

3. Final Answer:

   main -> Option A

4. Quick Check:

   Global settings = main [OK]

Hint: Global settings go in main context only [OK]

Common Mistakes:

• Confusing http with main context
• Placing global settings inside server or location
• Thinking events is for global settings

2. Which of the following is the correct way to nest the server context inside nginx configuration?

easy

A. main { server { ... } }

B. http { server { ... } }

C. events { server { ... } }

D. location { server { ... } }

Solution

1. Step 1: Recall nginx context hierarchy

   The server context must be inside the http context.

2. Step 2: Check each option's nesting

   Only http { server { ... } } is valid nesting; others are invalid.

3. Final Answer:

   http { server { ... } } -> Option B

4. Quick Check:

   server inside http = correct [OK]

Hint: Server blocks go inside http context [OK]

Common Mistakes:

• Placing server inside main or events
• Nesting server inside location
• Confusing events with http context

3. Given this nginx snippet, what is the correct context for the listen 80; directive?

http {
  server {
    listen 80;
    location / {
      root /var/www/html;
    }
  }
}

medium

A. server

B. events

C. main

D. location

Solution

1. Step 1: Identify where listen directive belongs

   The listen directive configures the port for a virtual host, which belongs in the server context.

2. Step 2: Check the snippet structure

   In the snippet, listen 80; is inside server, which is correct.

3. Final Answer:

   server -> Option A

4. Quick Check:

   listen directive = server context [OK]

Hint: listen always goes inside server context [OK]

Common Mistakes:

• Placing listen inside location
• Thinking listen belongs in main or events
• Confusing location with server context

4. You wrote this nginx config but nginx fails to start:

events {
  server {
    worker_connections 1024;
  }
}

What is the error?

medium

A. Missing http context around server

B. worker_connections must be inside server

C. events context cannot contain any directives

D. server context cannot be inside events

Solution

1. Step 1: Understand events context usage

   The events context is for event-related directives only and cannot contain server blocks.

2. Step 2: Identify invalid nesting

   Placing server inside events is invalid and causes nginx startup failure.

3. Final Answer:

   server context cannot be inside events -> Option D

4. Quick Check:

   server inside events = invalid [OK]

Hint: server blocks never go inside events context [OK]

Common Mistakes:

• Putting server inside events
• Misplacing worker_connections inside server
• Confusing events with http context

5. You want to serve static files from /var/www/html only for URLs starting with /images/. Which context should you use to configure this in nginx?

hard

A. main

B. server

C. location

D. events

Solution

1. Step 1: Identify context for URL matching

   The location context is used to match specific URL patterns like /images/.

2. Step 2: Understand static file serving setup

   Inside location, you set the root directive to serve files from the desired folder.

3. Final Answer:

   location -> Option C

4. Quick Check:

   URL-specific config = location context [OK]

Hint: Use location for URL path specific settings [OK]

Common Mistakes:

• Trying to serve files from main or events
• Placing root directive in server without location
• Confusing server and location contexts