Upstream blocks in Nginx - Step-by-Step Execution

Process Flow - Upstream blocks

Define upstream block

↓

List backend servers

↓

Configure load balancing method

↓

Use upstream name in server block

↓

Client request arrives

↓

Proxy request to one backend server

↓

Receive response and send to client

The upstream block defines backend servers and load balancing. The server block uses this name to proxy client requests to those backends.

Execution Sample

Nginx

upstream backend {
    server 192.168.1.10;
    server 192.168.1.11;
}

server {
    location / {
        proxy_pass http://backend;
    }
}

Defines two backend servers in an upstream block and proxies client requests to them using load balancing.

Process Table

Step	Action	Details	Result
1	Read upstream block	Identify 'backend' with servers 192.168.1.10 and 192.168.1.11	Upstream 'backend' created with 2 servers
2	Read server block	Location '/' proxies to 'http://backend'	Proxy setup to use upstream 'backend'
3	Client sends request	Request arrives at nginx server	Request received
4	Select backend server	Load balancing chooses 192.168.1.10 (default round-robin)	Request forwarded to 192.168.1.10
5	Backend responds	192.168.1.10 sends response	Response received by nginx
6	Send response to client	Nginx forwards backend response	Client receives response
7	Next client request	Load balancing chooses 192.168.1.11	Request forwarded to 192.168.1.11
8	Repeat response forwarding	Backend 192.168.1.11 responds	Client receives response
9	No more requests	End of trace	Execution stops

💡 No more client requests to proxy, execution ends

Status Tracker

Variable	Start	After 1	After 2	Final
upstream 'backend' servers	empty	[192.168.1.10, 192.168.1.11]	[192.168.1.10, 192.168.1.11]	[192.168.1.10, 192.168.1.11]
current backend server	none	192.168.1.10	192.168.1.11	none
client request count	0	1	2	2

Key Moments - 3 Insights

Why does nginx choose 192.168.1.10 first and then 192.168.1.11?

Nginx uses round-robin load balancing by default, so it cycles through the servers in order as shown in steps 4 and 7 of the execution_table.

What happens if one backend server is down?

Nginx will skip the down server and send requests to the available ones. This is not shown in the current trace but is part of upstream block behavior.

Why do we use an upstream block instead of directly proxying to an IP?

The upstream block groups multiple servers and enables load balancing and easier management, as seen in step 1 and 2 of the execution_table.

Visual Quiz - 3 Questions

Look at the execution_table, which backend server handles the first client request?

A 192.168.1.11

B Both servers simultaneously

C 192.168.1.10

D No backend server

💡 Hint

Check step 4 in the execution_table where the first backend server is selected.

At which step does nginx forward the second client request to the backend?

A Step 5

B Step 7

C Step 3

D Step 9

💡 Hint

Look at the execution_table row describing the next client request forwarding.

If a third server 192.168.1.12 is added to the upstream, how would the variable 'upstream servers' change after step 1?

A [192.168.1.10, 192.168.1.11, 192.168.1.12]

B [192.168.1.12]

C [192.168.1.10, 192.168.1.11]

D No change

💡 Hint

Refer to variable_tracker for 'upstream servers' after step 1.

Concept Snapshot

upstream backend {
    server IP1;
    server IP2;
}

Use proxy_pass http://backend; in server block.
Nginx load balances requests to backend servers.
Default method is round-robin.
Upstream groups servers for easier management.

Full Transcript

An upstream block in nginx defines a group of backend servers. The server block uses the upstream name to proxy client requests. When a client sends a request, nginx selects a backend server using load balancing (default round-robin) and forwards the request. The backend responds, and nginx sends the response back to the client. This process repeats for each client request, cycling through the backend servers. The upstream block simplifies managing multiple servers and enables load balancing automatically.

Practice

1. What is the main purpose of an upstream block in an nginx configuration?

easy

A. To set caching rules for static files

B. To group backend servers for load balancing

C. To define client request headers

D. To configure SSL certificates

Solution

1. Step 1: Understand the role of upstream blocks

   Upstream blocks in nginx are used to group backend servers together.

2. Step 2: Identify the purpose of grouping

   This grouping allows nginx to distribute incoming traffic among these servers, which is called load balancing.

3. Final Answer:

   To group backend servers for load balancing -> Option B

4. Quick Check:

   Upstream blocks = backend server groups [OK]

Hint: Upstream blocks group servers for load balancing [OK]

Common Mistakes:

• Confusing upstream with SSL or caching settings
• Thinking upstream defines client headers
• Assuming upstream is for static file rules

2. Which of the following is the correct syntax to define an upstream block named backend with two servers server1.example.com and server2.example.com?

easy

A. upstream backend { server server1.example.com; server server2.example.com; }

B. upstream backend { server1.example.com; server2.example.com; }

C. upstream backend { backend server1.example.com; backend server2.example.com; }

D. upstream backend { server: server1.example.com; server: server2.example.com; }

Solution

1. Step 1: Recall the upstream block syntax

   The correct syntax requires the keyword server before each backend server address inside curly braces.

2. Step 2: Match the syntax with options

   upstream backend { server server1.example.com; server server2.example.com; } correctly uses server server1.example.com; and server server2.example.com; inside the upstream block.

3. Final Answer:

   upstream backend { server server1.example.com; server server2.example.com; } -> Option A

4. Quick Check:

   Each backend needs 'server' keyword [OK]

Hint: Each server line starts with 'server' keyword [OK]

Common Mistakes:

• Omitting 'server' keyword before addresses
• Using colons instead of spaces
• Adding extra keywords like 'backend' inside block

3. Given this nginx upstream block:

upstream backend {
    server 192.168.1.10 weight=3;
    server 192.168.1.11;
}

What does the weight=3 mean for 192.168.1.10?

medium

A. It receives three times more requests than 192.168.1.11

B. It is a backup server and only used if 192.168.1.11 fails

C. It limits connections to 3 simultaneous clients

D. It will be ignored because weight is invalid here

Solution

1. Step 1: Understand weight in upstream servers

   The weight parameter assigns relative load share to a server. A higher weight means more requests.

2. Step 2: Interpret the weight=3 for 192.168.1.10

   Since 192.168.1.10 has weight=3 and 192.168.1.11 has default weight=1, the first server gets 3 times more requests.

3. Final Answer:

   It receives three times more requests than 192.168.1.11 -> Option A

4. Quick Check:

   Weight controls request distribution [OK]

Hint: Weight multiplies request share for that server [OK]

Common Mistakes:

• Confusing weight with backup role
• Thinking weight limits connections
• Assuming weight is ignored if not 1

4. Identify the error in this upstream block configuration:

upstream backend {
    server 10.0.0.1;
    server 10.0.0.2 backup;
    server 10.0.0.3 weight=two;
}

medium

A. Upstream block cannot have more than two servers

B. Backup server must be listed first

C. Missing semicolon after server 10.0.0.1

D. The weight value 'two' is invalid; it must be a number

Solution

1. Step 1: Check syntax of weight parameter

   The weight parameter must be a numeric value. 'two' is a string and invalid.

2. Step 2: Verify other parts of the block

   Semicolons are present, backup server can be anywhere, and multiple servers are allowed.

3. Final Answer:

   The weight value 'two' is invalid; it must be a number -> Option D

4. Quick Check:

   Weight must be numeric [OK]

Hint: Weight values must be numbers, not words [OK]

Common Mistakes:

• Placing backup server only first
• Forgetting semicolons
• Limiting number of servers incorrectly

5. You want to configure an upstream block named app_servers with three servers: 10.1.1.1 (weight 5), 10.1.1.2 (weight 1), and 10.1.1.3 as a backup. Which configuration is correct?

hard

A. upstream app_servers { server 10.1.1.1 weight=5; server 10.1.1.2; server 10.1.1.3 backup=1; }

B. upstream app_servers { server 10.1.1.1 weight=5; server 10.1.1.2 weight=1 backup; server 10.1.1.3; }

C. upstream app_servers { server 10.1.1.1 weight=5; server 10.1.1.2 weight=1; server 10.1.1.3 backup; }

D. upstream app_servers { server 10.1.1.1; server 10.1.1.2 weight=1; server 10.1.1.3 backup weight=5; }

Solution

1. Step 1: Assign weights correctly

   Servers 10.1.1.1 and 10.1.1.2 must have weights 5 and 1 respectively, using weight=.

2. Step 2: Mark backup server properly

   Server 10.1.1.3 should be marked with the backup keyword without weight.

3. Step 3: Validate options

   upstream app_servers { server 10.1.1.1 weight=5; server 10.1.1.2 weight=1; server 10.1.1.3 backup; } correctly assigns weights and backup keyword. Others misuse backup or weight syntax.

4. Final Answer:

   upstream app_servers { server 10.1.1.1 weight=5; server 10.1.1.2 weight=1; server 10.1.1.3 backup; } -> Option C

5. Quick Check:

   Weight and backup keywords used correctly [OK]

Hint: Use 'weight=' for load, 'backup' alone for backup server [OK]

Common Mistakes:

• Using 'backup=1' instead of 'backup'
• Combining weight and backup on same server
• Omitting weight for weighted servers