Test your knowledge: Nginx Proxy & Gateway

Question 1 of 6

`location /api/ { proxy_pass http://backend/v1/; }` — a request for `/api/users` is forwarded as what?

A URI part on proxy_pass replaces the matched location prefix.

Answer options A /api/users unchanged B /v1/users C /v1/api/users D /users

With a URI, proxy_pass replaces the /api/ prefix with /v1/. Without a URI (just http://backend) the full original path passes through. Getting this wrong is the number-one proxying bug.

Review this lesson

Question 2 of 6

Your backend logs the NGINX box's IP as the client. Which header chain fixes the real-client view?

One header carries the value; the other carries the history.

Answer options A Host plus X-Forwarded-Proto B X-Real-IP for the direct value, X-Forwarded-For for the accumulating chain across hops C X-Origin-IP set once at the edge D Forwarded only — the other two are deprecated aliases

X-Real-IP is the single address you trust (usually $remote_addr at the edge). X-Forwarded-For appends each hop so the backend can see the whole chain — trusting it blindly lets clients spoof.

Review this lesson

Question 3 of 6

Proxying WebSockets requires which essential header handling?

The hop-by-hop headers must survive the handshake — and only when the client actually upgrades.

Answer options A Setting Upgrade and Connection to the values the client sent — conventionally via map $http_upgrade B Nothing special — proxy_pass handles the handshake C Forcing Connection: keep-alive on both legs D Adding X-WebSocket: true

The Upgrade/Connection pair is hop-by-hop: it applies to one leg, so NGINX must forward it explicitly. A map on $http_upgrade passes the client's value when upgrading and clears it otherwise — the canonical pattern.

Review this lesson

Question 4 of 6

PHP-FPM is reached with `fastcgi_pass`, not `proxy_pass`. What is the difference?

The backend speaks a different wire protocol.

Answer options A fastcgi_pass speaks the FastCGI protocol over the connection; proxy_pass speaks HTTP B fastcgi_pass is only a unix-socket directive C proxy_pass cannot reach localhost D They are aliases — the choice is stylistic

PHP-FPM talks FastCGI, not HTTP — fastcgi_pass (with fastcgi_param wiring like SCRIPT_FILENAME) bridges it. uWSGI and SCGI get their own peers for the same reason: different protocols, different directives.

Review this lesson

Question 5 of 6

`proxy_next_upstream error timeout;` controls what?

It is the retry policy for failed attempts.

Answer options A Which client errors get retried on the same upstream B The conditions under which a failed attempt transparently retries on the next server in the upstream group C How long NGINX waits before declaring an upstream dead D The order servers are tried in

When an attempt fails with a listed condition — connection error, timeout, or optionally certain HTTP statuses — NGINX retries the request on the next server in the pool, bounded by proxy_next_upstream_tries and _timeout.

Review this lesson

Question 6 of 6

Serving gRPC through NGINX uses `grpc_pass` over HTTP/2. What does TLS-terminating at the edge require there?

gRPC is HTTP/2 end to end — the backend leg cannot downgrade.

Answer options A Nothing — gRPC ignores TLS B The upstream leg also needs HTTP/2: grpc_pass speaks h2 to the backend (often with its own TLS or h2c) C Downgrading to HTTP/1.1 for the backend D A separate stream{} block

grpc_pass terminates client h2 (and TLS), then speaks HTTP/2 to the backend — plain h2c or TLS. The backend leg must be an HTTP/2 server, which is why gRPC backends and grpc_pass come as a pair.

Review this lesson

Test your knowledge: Nginx Proxy & Gateway