Test your knowledge: Nginx Load Balancing

Upstream pools, scheduling algorithms, failure handling, keepalive, and health checks.

Stuck? Each question has an optional hint.

Skip a hard question and review it before your results.

Questions and answer options can shuffle between attempts.

You can retake this quiz whenever you like.

Question 1 of 6

An `upstream` block with no scheduling directive uses which algorithm?

The default needs no directive at all.

Answer options A least_conn B round-robin — weighted when weight is set C ip_hash D random

Plain round-robin is the default, and per-server weight scales each peer's share. least_conn, ip_hash, random, and hash are opt-in alternatives.

Review this lesson

Question 2 of 6

Requests vary wildly in duration. Which scheduler keeps latency most even?

Count what is still in flight, not what has been sent.

Answer options A round-robin B least_conn — it sends each new request to the peer with the fewest active connections C ip_hash D hash $request_uri

When a few slow requests would otherwise pin one peer, least_conn routes around the backlog by watching active connections. round-robin is fair in count, not in load.

Review this lesson

Question 3 of 6

Sessions live in server memory, not shared. Which balancer preserves user-to-server affinity?

Same client, same hash, same peer.

Answer options A least_conn B ip_hash — the client IP hashes to a consistent peer C round-robin with weight 1 D split_clients

ip_hash turns the client address into a stable peer choice — sticky routing without cookies. The cost: uneven keys (NAT, VPNs) skew the distribution, and a dead peer rehashes its users.

Review this lesson

Question 4 of 6

`server 10.0.0.4 max_fails=3 fail_timeout=30s;` — what does this do?

No probe traffic is sent — the failures are observed in production.

Answer options A Actively probes the server every 30 seconds, 3 times B After 3 failures within 30s, the peer is quarantined for 30s — passive health checking C Retries each failed request 3 times with 30s spacing D Caps the server at 3 concurrent failures

This is open source NGINX's passive model: real traffic's failures mark the peer unavailable for fail_timeout. Active probing — synthetic health checks — is the NGINX Plus feature.

Review this lesson

Question 5 of 6

What does a `keepalive 32;` line inside an upstream block buy you?

It is about the backend leg.

Answer options A Client-side keep-alive for browsers B A warm connection pool to the backends, so requests skip the TCP handshake C Longer idle timeouts for clients D Session persistence across reloads

The pool holds idle keep-alive connections to upstream servers; proxy_http_version 1.1 plus cleared Connection headers reuse them. Each spared handshake is latency and CPU you keep.

Review this lesson

Question 6 of 6

You need failed servers removed from rotation without waiting for real traffic to notice. What is the open-source-native path?

The single biggest operational gap between OSS and Plus.

Answer options A health_check in the upstream block B There is no built-in — health_check is NGINX Plus; open source combines passive marking (max_fails/fail_timeout) with an external reconfigurer (probe route, log-driven reloads, or DNS) C active_check on; D resolver with a short valid period

Active health checks are the flagship Plus feature. On open source you combine passive marking (max_fails/fail_timeout) with OSS patterns: a probe route feeding the retry machinery, a log-driven orchestrator that marks peers down and reloads, or DNS-based reconfiguration for proactive removal (the dynamic upstream API itself is Plus).

Review this lesson

Test your knowledge: Nginx Load Balancing