Test your knowledge: Nginx Layer 4 Routing

The stream module: TCP/UDP proxying, the PROXY protocol, and SNI-based TLS passthrough.

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

A `stream { }` block differs from `http { }` how?

Layer 4 never sees a request line.

Answer options A It is only for TLS traffic B No HTTP parsing at all — raw TCP/UDP bytes routed and balanced per connection C It cannot load balance D It replaces the events block

stream{ } proxies connections, not requests: databases, brokers, mail, game servers. You get the same upstream toolbox (algorithms, failure handling) with connection granularity, and a log vocabulary of sessions, not requests.

Review this lesson

Question 2 of 6

Why does the PROXY protocol exist?

TCP has no X-Forwarded-For.

Answer options A To proxy HTTP headers over TCP B To carry the real client address/port across an L4 hop, since raw TCP forwarding rewrites nothing and the backend would only see the proxy's IP C To negotiate TLS on the backend leg D To multiplex many TCP connections over one

The PROXY protocol prepends one line (v1) or binary header (v2) with the connection's true endpoints before the payload. Both sides must agree on it: the sender enables proxy_protocol on its proxy_pass, and the receiver declares it on its listen socket.

Review this lesson

Question 3 of 6

UDP has no connections. What does 'UDP proxying' in the stream module actually manage?

NGINX manufactures the state UDP lacks.

Answer options A One socket per datagram B Synthesized sessions: a timeout-bounded mapping from client endpoint to upstream, so replies can route back C Broadcast groups D It tunnels UDP inside TCP

NGINX keys a session by the client address/port pair, holds it alive across a timeout, and pins it to one upstream socket so return traffic finds its way back — the state a NAT-like forwarder must invent.

Review this lesson

Question 4 of 6

TLS passthrough with SNI routing ( `ssl_preread on;`) works because of what property of TLS?

Peek, don't decrypt.

Answer options A The SNI hostname is sent in the TLS ClientHello, unencrypted, before the encrypted session starts B TLS certificates contain routing metadata C NGINX decrypts, reads SNI, and re-encrypts invisibly D QUIC exposes the hostname as a UDP payload header

The ClientHello's server_name extension is plaintext by design — ssl_preread peeks at it, a map on $ssl_preread_server_name picks the upstream, and the encrypted bytes flow through untouched. NGINX never holds a key.

Review this lesson

Question 5 of 6

In stream{ }, what does the balancer distribute?

Connection granularity is the L4 signature.

Answer options A HTTP requests within one connection B Whole connections — each TCP session goes to one upstream peer C Datagram halves D TLS sessions by SNI

One connection, one peer — chosen by the same algorithm family as http{} (round-robin, least_conn, hash). There is no per-request switching because there are no requests, only sessions.

Review this lesson

Question 6 of 6

The idiomatic SNI router in stream{ } is shaped how?

map beats if in stream{} too — declare, don’t branch.

Answer options A if ($ssl_preread_server_name = api.example.com) { ... } B A map $ssl_preread_server_name $backend { ... } feeding a single proxy_pass $backend; C One server { } block per hostname, all on one port D split_clients on the ClientHello bytes

map turns the peeked SNI into an upstream variable, and one proxy_pass consumes it — declarative, extensible, no phase-trap ifs. server blocks multiply only when TLS certificates or ports actually differ.

Review this lesson

Test your knowledge: Nginx Layer 4 Routing