NGINX Reverse Proxy and Load Balancing

Your client does not need to know where every application instance runs. It can send requests to one NGINX endpoint. NGINX then selects a backend, forwards the request, receives the response, and returns that response to the client.

That is the central mental model:

client → NGINX → backend
            └──→ backend
            └──→ backend

NGINX is the reverse proxy because it represents servers to clients. A forward proxy represents clients when they reach external resources.

Why put NGINX in the request path?

A reverse proxy gives you one place to route requests and control how they reach applications. You can use different location blocks to serve files, send requests to one server, or send requests to an upstream group.

An upstream group names a set of backend servers. When proxy_pass points to that group, NGINX chooses a server for each request. The default method is weighted round robin.

This arrangement helps you:

• Hide backend addresses from clients.
• Spread requests across application instances.
• Route different URI spaces to different services.
• Preserve one client-facing endpoint while backends change.
• Terminate client connections and manage separate upstream connections.
• Buffer responses so a slow client does not hold a backend busy for the entire download.

The extra hop also creates responsibility. NGINX becomes part of the application's behavior and failure path. You must define request headers, URI mapping, timeouts, retry behavior, logging, and upstream security deliberately.

The configuration map