Nginx as a Reverse Proxy

In one line

Nginx sits in front of your app, accepts client connections, and forwards requests to upstream servers; a handful of directives (server, location, upstream, proxy_pass, headers, timeouts) cover most real configs.

0/4 · 0%

Think of it like this

A hotel front desk. Guests never walk into the kitchen or the laundry; they talk to the desk, which forwards requests to the right department and brings back the result. The departments never deal with guests directly.

Key ideas

01
Structure: http holds server blocks (one per site, matched by listen port and server_name), each with location blocks matched by path. upstream defines a group of backends with a balancing method.
02
proxy_pass http://app; forwards the request. Pass the original details on with headers: Host, X-Real-IP, X-Forwarded-For, X-Forwarded-Proto. The app then sees the real client rather than Nginx (Topic 4.3 explains why proxies hide the client).
03
Timeouts decide 502 vs 504 behaviour: proxy_connect_timeout, proxy_read_timeout, proxy_send_timeout. Keep-alive to upstreams (keepalive in the upstream block plus proxy_http_version 1.1) avoids a new TCP handshake per request (Topic 2.2).
04
Always validate before reloading: nginx -t checks syntax, and nginx -s reload applies changes gracefully without dropping connections.

Code & diagrams

ReverseProxydiagram

Rendering diagram…

Explain it without notes

Why must a reverse proxy add X-Forwarded-For and X-Forwarded-Proto headers?

Practice

After a config change, how do you apply it safely without dropping live connections?

Trade-offs

↔
A reverse proxy centralises routing, headers, and protection in one place, at the cost of an extra hop and another component to configure, monitor, and scale.

Done when you can

I understand server, location, upstream, and proxy_pass.
I know which headers to forward and which timeouts matter.
I validate and reload Nginx safely.