Reverse Proxy Basics

Analogy categoryAnalogies

What Is a Reverse Proxy?

A reverse proxy is a server that sits in front of one or more backend (origin) servers and intercepts client requests on their behalf. When a browser or API client connects to nginx, it terminates that connection, inspects the request, and forwards it to an appropriate backend over a separate connection, then relays the backend's response back to the client as if nginx itself had produced it. This indirection lets nginx centralize concerns like TLS termination, compression, request routing, and caching without any backend application knowing the client's connection ever passed through an intermediary.

🏏

Cricket analogy: Think of nginx as the non-striker relaying a signal from the pavilion to the striker mid-over — the bowler (client) only ever interacts with the batsman at the crease, never knowing a message was routed through someone else standing between them.

Reverse Proxy vs Forward Proxy

A forward proxy sits in front of clients and represents them to the outside world — a corporate web filter that all employees dial out through is a forward proxy. A reverse proxy does the opposite: it sits in front of servers and represents them to the outside world, so external clients only ever see nginx's IP and hostname, never the real application servers behind it. Because nginx owns that boundary, it can add TLS termination, gzip compression, response caching, and IP-based access control uniformly for every backend, regardless of what language or framework each backend is written in.

🏏

Cricket analogy: A forward proxy is like a team manager who filters every media request from players before it reaches a journalist, while a reverse proxy is like the team's press officer who answers all journalist questions on behalf of players who never speak directly to the press.

Basic proxy_pass Configuration

nginx

server {
    listen 80;
    server_name app.example.com;

    location /app/ {
        proxy_pass http://127.0.0.1:5000/api/;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

The proxy_pass directive inside a location block determines exactly how nginx rewrites the request URI before forwarding it. If proxy_pass has a trailing slash and a URI path, as in proxy_pass http://backend/api/, nginx replaces the matched location prefix with that path — so a request to /app/status hitting location /app/ becomes /api/status upstream. Omit the trailing slash, as in proxy_pass http://backend, and nginx instead appends the entire original URI unchanged after the matched prefix, forwarding /app/status as /app/status. This single trailing-slash difference is one of the most common sources of broken routing in nginx reverse proxy setups.

🏏

Cricket analogy: It's like a fielding captain's exact hand signal at mid-off — a slight wrist rotation (the trailing slash) tells the fielder to stand at a completely different spot than the same signal without that rotation, and misreading it puts the fielder out of position for the next ball.

Forwarding Headers to Backend

Because nginx terminates the client's TCP and TLS connection, the backend application only ever sees a connection coming from nginx's own internal IP over plain HTTP, losing the original client's identity and protocol. The proxy_set_header directive restores that context: Host preserves the domain the client actually requested (critical for virtual-host-aware apps), X-Real-IP and X-Forwarded-For pass along the client's real IP address for logging and rate limiting, and X-Forwarded-Proto tells the backend whether the original request was HTTPS so it can generate correct absolute URLs and avoid mixed-content redirect loops.

🏏

Cricket analogy: It's like a stand-in umpire relaying the original umpire's exact reasoning for an lbw decision to the third umpire, rather than just saying 'out' — without that context, the review can reach the wrong conclusion.

proxy_set_header directives are inherited from the enclosing http, server, or location block into nested location blocks — but only if the nested block does not define any proxy_set_header of its own. Defining even one header resets inheritance for all headers in that block, so it's safest to repeat the full header set explicitly in every location that proxies traffic.

Forgetting X-Forwarded-Proto is a classic cause of infinite redirect loops: a backend framework configured to force HTTPS sees an incoming plain HTTP request from nginx (since TLS was already terminated) and issues an HTTPS redirect, which nginx again proxies as HTTP, looping indefinitely.

A reverse proxy terminates client connections and forwards requests to backend servers on their behalf, hiding backend topology.
Forward proxies represent clients; reverse proxies represent servers — nginx is almost always used as the latter.
proxy_pass with a trailing slash and path replaces the matched location prefix; without it, the full original URI is appended.
proxy_set_header restores Host, X-Real-IP, X-Forwarded-For, and X-Forwarded-Proto that are otherwise lost when nginx terminates the client connection.
Header inheritance breaks once any proxy_set_header is redefined in a nested location block, so repeat the full set explicitly.
A missing X-Forwarded-Proto header is a common cause of infinite HTTPS redirect loops.
Reverse proxies let TLS termination, compression, and caching be centralized in one place instead of duplicated per backend.