Server block structure in Nginx - Step-by-Step Execution

Process Flow - Server block structure

Start nginx config

↓

Define server block

↓

Set listen port

↓

Set server_name

↓

Define location blocks

↓

Specify root or proxy settings

↓

Close server block

↓

nginx reads next block or ends

nginx reads the config file, finds server blocks, applies settings like port, domain, and content handling inside each block.

Execution Sample

Nginx

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

Defines a server block listening on port 80 for example.com, serving files from /var/www/html for root URL.

Process Table

Step	Config Line Read	Action Taken	Current Server Block State	Notes
1	server {	Start new server block	server block started, empty settings	Begin server block parsing
2	listen 80;	Set listen port to 80	listen=80	Server listens on port 80
3	server_name example.com;	Set server_name	listen=80, server_name=example.com	Domain set for this server
4	location / {	Start location block for /	listen=80, server_name=example.com, location=/ started	Defines root URL handling
5	root /var/www/html;	Set root directory	location=/ root=/var/www/html	Files served from this directory
6	}	Close location block	location block closed	End location settings
7	}	Close server block	server block closed with listen=80, server_name=example.com, location root set	Server block complete
8	EOF	End of config file	All server blocks parsed	nginx ready to use this config

💡 Reached end of server block and config file; nginx has full server block settings.

Status Tracker

Variable	Start	After Step 2	After Step 3	After Step 5	Final
listen	unset	80	80	80	80
server_name	unset	unset	example.com	example.com	example.com
location	unset	unset	unset	/	/
root	unset	unset	unset	/var/www/html	/var/www/html

Key Moments - 3 Insights

Why do we need to close the location and server blocks with '}'?

Each '}' tells nginx the current block ends. Without it, nginx can't know where settings stop. See execution_table steps 6 and 7 where blocks close.

What happens if we omit the listen directive?

nginx uses default port 80 if listen is missing. In execution_table step 2, listen is set explicitly; if missing, nginx assumes 80.

Can we have multiple location blocks inside one server block?

Yes, each location handles different URL paths. This example shows one location at step 4-6, but more can be added similarly.

Visual Quiz - 3 Questions

Look at the execution_table at step 3. What is the server_name set to?

A unset

B localhost

C example.com

D 80

💡 Hint

Check the 'Current Server Block State' column at step 3 in execution_table.

At which step does nginx finish reading the location block?

A Step 4

B Step 6

C Step 5

D Step 7

💡 Hint

Look for the action 'Close location block' in execution_table.

If we change 'listen 80;' to 'listen 8080;', what changes in variable_tracker after step 2?

A listen changes to 8080

B server_name changes to 8080

C root changes to 8080

D No change

💡 Hint

Variable 'listen' is set at step 2; check variable_tracker for 'listen' values.

Concept Snapshot

server {
  listen [port];          # Port to listen on (default 80)
  server_name [domain];   # Domain name for this server
  location [path] {       # URL path handling
    root [directory];     # Files served from here
  }
}
Close blocks with '}' to end settings.

Full Transcript

This visual execution shows how nginx reads a server block configuration. It starts with 'server {' to open the block, then sets the listen port and server_name. Inside, it defines a location block for URL path handling, setting the root directory for files. Each block is closed with '}'. Variables like listen, server_name, location, and root update step-by-step. Key points include the need to close blocks properly and default values if some directives are missing. The quiz checks understanding of server_name setting, block closing steps, and variable changes when modifying listen port.

Practice

1. What is the main purpose of a server block in an Nginx configuration?

easy

A. To define how Nginx handles requests for a specific website or domain

B. To set the operating system user for Nginx processes

C. To configure the firewall rules for Nginx

D. To specify the database connection details

Solution

1. Step 1: Understand the role of server blocks

   A server block tells Nginx how to respond to requests for a particular domain or site.

2. Step 2: Compare options with server block purpose

   Only To define how Nginx handles requests for a specific website or domain describes handling requests for a website, which matches the server block's role.

3. Final Answer:

   To define how Nginx handles requests for a specific website or domain -> Option A

4. Quick Check:

   Server block = website request handling [OK]

Hint: Server blocks map domains to settings in Nginx [OK]

Common Mistakes:

• Confusing server block with user or firewall settings
• Thinking server block manages database connections
• Mixing server block with global Nginx settings

2. Which of the following is the correct syntax to start a server block in Nginx?

easy

A. server {

B. block server {

C. site {

D. server-block {

Solution

1. Step 1: Recall Nginx server block syntax

   The correct syntax to start a server block is the keyword server followed by curly braces.

2. Step 2: Check each option

   Only server { uses the exact keyword server with braces, which is valid syntax.

3. Final Answer:

   server { -> Option A

4. Quick Check:

   Server block starts with 'server {' [OK]

Hint: Server blocks always start with 'server {' [OK]

Common Mistakes:

• Using incorrect keywords like 'block' or 'site'
• Adding extra hyphens or misspelling 'server'
• Omitting the opening brace

3. Given this server block snippet, what port will Nginx listen on?

server {
    listen 8080;
    server_name example.com;
}

medium

A. 443

B. 8080

C. 80

D. None, it will cause an error

Solution

1. Step 1: Identify the listen directive

   The line listen 8080; tells Nginx to listen on port 8080.

2. Step 2: Understand default ports

   Since port 8080 is explicitly set, Nginx will listen on 8080, not the default 80 or 443.

3. Final Answer:

   8080 -> Option B

4. Quick Check:

   listen port = 8080 [OK]

Hint: Check the listen directive for port number [OK]

Common Mistakes:

• Assuming default port 80 without checking listen
• Confusing port 443 (HTTPS) with 8080
• Thinking missing listen causes error (it defaults to 80)

4. Identify the error in this server block configuration:

server {
    listen 80
    server_name mysite.com;
}

medium

A. listen directive should be 'listen port 80;'

B. server_name directive is incorrect

C. Curly braces are missing

D. Missing semicolon after listen directive

Solution

1. Step 1: Check syntax of directives

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

2. Step 2: Verify other parts

   The server_name directive and braces are correct. The listen directive syntax does not require the word 'port'.

3. Final Answer:

   Missing semicolon after listen directive -> Option D

4. Quick Check:

   Directives end with ';' [OK]

Hint: Every directive line ends with a semicolon [OK]

Common Mistakes:

• Forgetting semicolons after directives
• Adding unnecessary words like 'port' in listen
• Misplacing or missing braces

5. You want to serve two websites on the same Nginx server: site1.com on port 80 and site2.com on port 8080. Which configuration correctly sets up the server blocks?

hard

A. server {
listen 80 8080;
server_name site1.com site2.com;
}

B. server {
listen 80;
server_name site1.com site2.com;
}

C. server {
listen 80;
server_name site1.com;
}
server {
listen 8080;
server_name site2.com;
}

D. server {
listen 80;
server_name site1.com;
listen 8080;
server_name site2.com;
}

Solution

1. Step 1: Understand separate server blocks for different ports

   Each site on a different port needs its own server block with its own listen and server_name directives.

2. Step 2: Analyze each option

   server { listen 80; server_name site1.com; } server { listen 8080; server_name site2.com; } correctly defines two separate server blocks, one for port 80 and site1.com, another for port 8080 and site2.com. Other options either combine ports or server_names incorrectly.

3. Final Answer:

   Separate server blocks for each site and port -> Option C

4. Quick Check:

   One server block per port/site [OK]

Hint: Use separate server blocks for different ports/sites [OK]

Common Mistakes:

• Combining multiple ports in one listen directive incorrectly
• Listing multiple server_names in one block for different ports
• Trying to put two listen directives in one server block for different sites