Upstream blocks in Nginx - Practice Problems & Coding Challenges

Challenge - 5 Problems

💻 Command Output

intermediate

What is the effect of this upstream block configuration?

Given the following nginx upstream block, what will be the behavior when a client request is proxied to backend?

Nginx

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

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

A Requests will be distributed with 75% going to 192.168.1.10 and 25% to 192.168.1.11 based on weights.

B Requests will be sent only to 192.168.1.10 because it has the highest weight.

C Requests will be sent only to 192.168.1.11 because it has the lowest weight.

D Requests will be distributed equally between 192.168.1.10 and 192.168.1.11 regardless of weights.

💡 Hint

Weights in upstream blocks control the proportion of requests sent to each server.

The weight parameter in an nginx upstream block controls how many requests each server receives relative to others. Here, 192.168.1.10 has weight 3 and 192.168.1.11 has weight 1, so 3 out of 4 requests (75%) go to the first server, and 1 out of 4 (25%) to the second.

❓ Troubleshoot

intermediate

Why does nginx fail to start with this upstream block?

Examine the following nginx configuration snippet. Why will nginx fail to start?

Nginx

upstream backend {
    server 192.168.1.10:8080;
    server 192.168.1.11:8080 max_fails=3 fail_timeout=30s;
    server 192.168.1.12:8080 max_fails=two fail_timeout=30s;
}

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

A The upstream block must have at least four servers defined.

B The value 'two' for max_fails is invalid; it must be a number.

C The fail_timeout value must be in milliseconds, not seconds.

D The port 8080 is not allowed in upstream blocks.

💡 Hint

Check the data types of parameters in the upstream block.

The max_fails parameter expects a numeric value. Using the word 'two' instead of a number causes a syntax error, preventing nginx from starting.

❓ Configuration

advanced

Which upstream block configuration enables session persistence using IP hash?

Select the correct nginx upstream block configuration that ensures requests from the same client IP always go to the same backend server.

A

upstream backend {
    ip_hash;
    server 192.168.1.10;
    server 192.168.1.11;
}

B

upstream backend {
    least_conn;
    server 192.168.1.10;
    server 192.168.1.11;
}

C

upstream backend {
    server 192.168.1.10;
    server 192.168.1.11;
    sticky;
}

D

upstream backend {
    server 192.168.1.10;
    server 192.168.1.11;
    hash $remote_addr;
}

💡 Hint

Look for the directive that explicitly enables IP-based session persistence.

The ip_hash; directive in an nginx upstream block ensures that requests from the same client IP address are always sent to the same backend server, enabling session persistence.

Option A uses hash $remote_addr which is valid for consistent hashing on IP but ip_hash is the specific directive for IP hash method. Option A uses sticky which requires a third-party module and is not standard. Option A uses least_conn which balances based on least connections, not IP.

✅ Best Practice

advanced

What is the recommended way to mark a backend server as temporarily unavailable in an upstream block?

You want nginx to stop sending requests to a backend server temporarily without removing it from the configuration. Which is the best way to do this?

A Remove the server line and reload nginx configuration.

B Comment out the server line in the upstream block.

C Use the 'down' parameter in the server line inside the upstream block.

D Set the server weight to zero.

💡 Hint

Look for a parameter that disables a server without deleting its config.

The down parameter marks a server as unavailable. Nginx will not send requests to it but keeps the configuration intact. This is useful for temporary maintenance.

Commenting out or removing the server line requires config changes and reloads. Setting weight to zero also excludes the server from load balancing but down is more explicit and the recommended parameter for this purpose.

🔀 Workflow

expert

Order the steps to safely update an nginx upstream block without dropping client connections

You need to update the list of backend servers in an nginx upstream block without interrupting active client connections. What is the correct order of steps?

A 3,1,2,4

B 2,1,3,4

C 1,3,2,4

D 1,2,3,4

💡 Hint

Think about safe config changes and validation before applying.

The safe workflow is to first edit the config, then test it with nginx -t to catch errors. If the test passes, reload nginx to apply changes without dropping connections. Finally, verify traffic flows to new backends.