Main configuration file (nginx.conf) - Step-by-Step Execution

Process Flow - Main configuration file (nginx.conf)

Start nginx service

↓

Read nginx.conf file

↓

Parse main context

↓

Parse events block

↓

Parse http block

↓

Parse server blocks inside http

↓

Apply configuration settings

↓

Start worker processes

↓

Listen for requests and serve

nginx starts by reading nginx.conf, parsing main, events, and http blocks, then applies settings and starts workers to serve requests.

Execution Sample

Nginx

worker_processes  1;
events {
  worker_connections  1024;
}
http {
  server {
    listen 80;
  }
}

This config sets 1 worker process, allows 1024 connections, and listens on port 80 for HTTP requests.

Process Table

Step	Config Section	Directive	Value	Effect
1	main	worker_processes	1	Set number of worker processes to 1
2	events	worker_connections	1024	Allow each worker to handle 1024 connections
3	http	server block start	-	Begin server configuration
4	server	listen	80	Server listens on port 80
5	end	-	-	Configuration parsing complete, nginx ready to start workers

💡 All configuration directives parsed successfully; nginx ready to start serving.

Status Tracker

Directive	Default	After Config
worker_processes	auto	1
worker_connections	512	1024
listen port	none	80

Key Moments - 2 Insights

Why does nginx need the worker_processes directive?

worker_processes controls how many processes handle requests. In the execution_table step 1, setting it to 1 means nginx uses one process to manage connections.

What happens if the listen directive is missing in the server block?

Without listen (see step 4), nginx won't know which port to accept requests on, so the server won't respond to HTTP traffic.

Visual Quiz - 3 Questions

Look at the execution_table at step 2, what does worker_connections set?

A Number of worker processes

B Maximum connections per worker

C Port number to listen on

D Timeout for connections

💡 Hint

Refer to execution_table row with step 2 under 'Directive' and 'Effect' columns.

At which step does nginx start listening on port 80?

A Step 4

B Step 1

C Step 3

D Step 5

💡 Hint

Check execution_table 'Config Section' and 'Directive' columns for 'listen' directive.

If worker_processes was set to 4, how would variable_tracker change?

A listen port would change to 4

B worker_connections would be 4

C worker_processes would be 4 after config

D No change in variable_tracker

💡 Hint

Look at variable_tracker row for worker_processes and how it updates after config.

Concept Snapshot

nginx.conf is the main config file.
It sets worker_processes (how many workers run).
The events block sets worker_connections (max connections per worker).
The http block contains server blocks.
Server blocks define listen ports and request handling.
nginx reads and applies these settings on start.

Full Transcript

The nginx main configuration file, nginx.conf, controls how nginx runs. When nginx starts, it reads this file. It first processes the main context, then the events block where it sets how many connections each worker can handle. Next, it reads the http block, which contains server blocks. Each server block defines which port to listen on and how to handle requests. For example, setting worker_processes to 1 means nginx runs one worker process. Setting worker_connections to 1024 means each worker can handle up to 1024 connections. The listen directive inside a server block tells nginx which port to accept requests on, such as port 80 for HTTP. After parsing all directives, nginx starts the worker processes and begins serving requests. This flow ensures nginx is configured correctly before it runs.

Practice

1. What is the primary purpose of the nginx.conf file in NGINX?

easy

A. To manage user accounts and permissions

B. To store website content like HTML and images

C. To log errors and access information

D. To configure how NGINX handles web requests and server behavior

Solution

1. Step 1: Understand the role of nginx.conf

   The nginx.conf file is the main configuration file that controls how NGINX behaves and processes requests.

2. Step 2: Differentiate from other files

   Files like logs store errors or access info, and website content files hold HTML/images, but nginx.conf sets server rules.

3. Final Answer:

   To configure how NGINX handles web requests and server behavior -> Option D

4. Quick Check:

   Main config file = server behavior [OK]

Hint: Remember: nginx.conf sets server rules, not content or logs [OK]

Common Mistakes:

• Confusing nginx.conf with website files
• Thinking nginx.conf stores logs
• Assuming nginx.conf manages users

2. Which of the following is the correct syntax to include another configuration file inside nginx.conf?

easy

A. include /etc/nginx/conf.d/*.conf;

B. import /etc/nginx/conf.d/*.conf;

C. load /etc/nginx/conf.d/*.conf;

D. attach /etc/nginx/conf.d/*.conf;

Solution

1. Step 1: Recall the directive for including files

   NGINX uses the include directive to add other config files inside nginx.conf.

2. Step 2: Check syntax correctness

   The correct syntax is include path; with a semicolon. Other words like import, load, attach are invalid in NGINX.

3. Final Answer:

   include /etc/nginx/conf.d/*.conf; -> Option A

4. Quick Check:

   Include directive = include [OK]

Hint: Use 'include' to add files, ends with semicolon [OK]

Common Mistakes:

• Using 'import' or 'load' instead of 'include'
• Forgetting the semicolon at the end
• Wrong directive names

3. Given this snippet from nginx.conf:

http {
    server {
        listen 80;
        server_name example.com;
        location / {
            root /var/www/html;
        }
    }
}

What will happen when a user visits http://example.com/?

medium

A. NGINX serves files from /var/www/html directory

B. NGINX returns a 404 error because root is missing a semicolon

C. NGINX redirects to HTTPS automatically

D. NGINX blocks the request due to missing listen directive

Solution

1. Step 1: Analyze the server block

   The server listens on port 80 and responds to requests for example.com. The location / block sets the root directory to /var/www/html.

2. Step 2: Understand the effect of root directive

   When a user visits the site root, NGINX serves files from /var/www/html. The semicolon is present, so syntax is correct.

3. Final Answer:

   NGINX serves files from /var/www/html directory -> Option A

4. Quick Check:

   Root directive sets file location = serve files [OK]

Hint: Root directive points to file folder served [OK]

Common Mistakes:

• Assuming missing semicolon causes error (it's present)
• Thinking HTTPS redirect happens automatically
• Ignoring listen directive presence

4. Identify the error in this nginx.conf snippet:

http {
    server {
        listen 80
        server_name mysite.com;
        location / {
            root /usr/share/nginx/html;
        }
    }
}

medium

A. root directive path is incorrect

B. server_name directive is invalid

C. Missing semicolon after listen 80

D. location block cannot be inside server block

Solution

1. Step 1: Check syntax of directives

   Each directive must end with a semicolon. The line listen 80 is missing a semicolon.

2. Step 2: Validate other directives

   The server_name and root directives are correctly written. The location block is correctly nested inside server.

3. Final Answer:

   Missing semicolon after listen 80 -> Option C

4. Quick Check:

   Every directive ends with semicolon [OK]

Hint: Check every directive ends with semicolon [OK]

Common Mistakes:

• Ignoring missing semicolon errors
• Thinking server_name syntax is wrong
• Misunderstanding block nesting rules

5. You want to serve two websites on the same NGINX server using nginx.conf. Which configuration correctly sets up two server blocks for site1.com and site2.com on port 80?

hard

A. http {
server {
listen 80;
server_name site1.com site2.com;
root /var/www/site1;
}
}

B. http {
server {
listen 80;
server_name site1.com;
root /var/www/site1;
}
server {
listen 80;
server_name site2.com;
root /var/www/site2;
}
}

C. http {
server {
listen 80;
server_name site1.com;
root /var/www/site1;
}
location /site2 {
root /var/www/site2;
}
}

D. http {
server {
listen 80;
server_name site1.com;
root /var/www/site1;
}
server {
listen 8080;
server_name site2.com;
root /var/www/site2;
}
}

Solution

1. Step 1: Understand multiple server blocks

   To serve two sites on the same port, create two separate server blocks each with its own server_name and root.

2. Step 2: Evaluate each option

   http {
       server {
           listen 80;
           server_name site1.com;
           root /var/www/site1;
       }
       server {
           listen 80;
           server_name site2.com;
           root /var/www/site2;
       }
   }

   correctly defines two server blocks both listening on port 80 with different server_name and root.

   http {
       server {
           listen 80;
           server_name site1.com site2.com;
           root /var/www/site1;
       }
   }

   combines names in one block, serving only one root.

   http {
       server {
           listen 80;
           server_name site1.com;
           root /var/www/site1;
       }
       location /site2 {
           root /var/www/site2;
       }
   }

   uses location incorrectly for separate site.

   http {
       server {
           listen 80;
           server_name site1.com;
           root /var/www/site1;
       }
       server {
           listen 8080;
           server_name site2.com;
           root /var/www/site2;
       }
   }

   uses different ports, not both on 80.

3. Final Answer:

   Two server blocks on port 80 with separate server_name and root -> Option B

4. Quick Check:

   Separate server blocks = separate sites [OK]

Hint: Use separate server blocks with unique server_name for each site [OK]

Common Mistakes:

• Combining multiple domains in one server block with one root
• Using location blocks instead of server blocks for separate sites
• Assigning different ports when same port is required