Upstream blocks in Nginx - Commands & Configuration

Introduction

When you want to send user requests to multiple servers to share the work, you use upstream blocks in nginx. They help balance traffic so no single server gets too busy.

When you have a website running on several servers and want nginx to send visitors to any of them.

When you want to improve your website speed by spreading requests across multiple backend servers.

When you want to keep your site working even if one server stops responding.

When you want to test a new server by sending some traffic to it without changing your main site.

When you want to organize your backend servers under one name for easier management.

Config File - nginx.conf

nginx.conf

http {
    upstream myapp {
        server 192.168.1.10:8080;
        server 192.168.1.11:8080;
        server 192.168.1.12:8080;
    }

    server {
        listen 80;

        location / {
            proxy_pass http://myapp;
        }
    }
}

The upstream block named myapp lists three backend servers by IP and port. This tells nginx to send requests to any of these servers.

The server block listens on port 80 and forwards all requests to the upstream group myapp using proxy_pass.

Commands

Check the nginx configuration file for syntax errors before restarting nginx.

Terminal

nginx -t

Expected Output

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok

nginx: configuration file /etc/nginx/nginx.conf test is successful

Reload nginx to apply the new configuration without stopping the service.

Terminal

systemctl reload nginx

Expected Output

No output (command runs silently)

Send a simple HTTP request to localhost to verify nginx is forwarding requests to the upstream servers.

Terminal

curl -I http://localhost

Expected Output

HTTP/1.1 200 OK

Server: nginx

Date: Wed, 01 Jan 2025 12:00:00 GMT

Content-Type: text/html

Content-Length: 612

Connection: keep-alive

Key Concept

If you remember nothing else from this pattern, remember: upstream blocks let nginx send user requests to multiple backend servers to share the load and improve reliability.

Common Mistakes

Forgetting to reload nginx after changing the upstream block.

Nginx keeps using the old configuration until reloaded, so changes won't take effect.

Always run 'nginx -t' to check config, then 'systemctl reload nginx' to apply changes.

Using incorrect IP addresses or ports in the upstream block.

Nginx cannot connect to backend servers if addresses or ports are wrong, causing errors or no response.

Verify backend server IPs and ports are correct and reachable before adding them.

Not using the upstream block name correctly in proxy_pass (e.g., missing 'http://' prefix).

Nginx will fail to proxy requests if the upstream name is not properly referenced.

Always use 'proxy_pass http://upstream_name;' to reference the upstream group.

Summary

Define backend servers inside an upstream block to group them under one name.

Use proxy_pass with the upstream name to forward requests to these servers.

Always test configuration syntax and reload nginx to apply changes safely.

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