Challenge 3: Two Different "Keep-Alive" Concepts — Solution Walkthrough

What client-facing keep-alive covers:

Web Servers Fundamentals' own keep-alive material (keepalive_timeout/
keepalive_requests) governs the connection between the client's
browser and Nginx itself — how long Nginx holds that connection open
so the same client can reuse it for multiple requests without
repeating a TCP (and TLS) handshake each time.

What the upstream keepalive directive covers instead:

This chapter's own keepalive directive, set inside an upstream {}
block, governs an entirely separate connection: the one between
Nginx itself and a backend server it's proxying requests to. It lets
Nginx reuse its own already-open connections to that backend across
multiple proxied requests, rather than opening a brand-new connection
to the backend for every single request forwarded to it.

Why both are genuinely called "keep-alive" without being the same
thing:

Both directives solve the identical underlying problem — avoiding the
overhead of repeatedly opening and closing TCP connections — but they
apply to two completely different legs of the request's journey:
client-to-Nginx in one case, Nginx-to-backend in the other. Tuning one
has no effect on the other; a server could have excellent
client-facing keep-alive and still open a fresh connection to its
backend on every single request if the upstream keepalive directive
were never configured.

WHY THIS WORKS AS AN ANSWER
------------------------------
This exercise checks that "keep-alive" is understood as a general
technique that gets applied independently to two different connection
legs, rather than assuming a single keep-alive setting covers the
entire request's journey end to end.