Reverse Proxies
- Pradeep P
- 3 days ago
- 4 min read
Layer 1 · Post 5 of 15
← Previous: Load Balancers → Next: API Gateways
Layer 1 — The building blocks · Post 5 of 88
A reverse proxy accepts traffic on behalf of your servers, then forwards it. It is the place you add TLS, buffering, routing, and protection.
What you'll learn
How a reverse proxy differs from a forward proxy
The jobs that usually live at this hop: TLS, routing, buffering, basic security
Why nginx, Envoy, and "the load balancer" often overlap in practice
The idea in one minute
A proxy is a middlebox. It takes a request meant for somewhere else and forwards it.
A forward proxy sits near the client (company outbound web filter, some VPNs). The client knows about it.
A reverse proxy sits near the servers. The client thinks it is talking to your website. Your servers think the proxy is the client.
Client → [ Reverse proxy ] → App / static files / another service
(your side)
If you have ever put nginx in front of a Node or Python app, you have used a reverse proxy.
Why it matters
Application processes are good at business logic. They are worse at being a public internet citizen: terminating TLS, soaking slow clients, hiding internal hostnames, serving a robots.txt, rate-limiting obvious abuse.
The reverse proxy is the specialist at the door. Keep the app boring. Let the proxy handle the messy edge.
It is also why so many diagrams show one box labeled "nginx / ALB / Envoy" doing three jobs at once. In production, load balancer, reverse proxy, and API gateway are overlapping roles, not three mandatory machines.
How it works
The client opens a connection to www.example.com. DNS points at the reverse proxy. The proxy:
Terminates TLS (HTTPS ends here, unless you re-encrypt to the backend).
Reads the request — path, host header, maybe cookies.
Picks a destination: this path goes to the app, that path to a static bucket, this host to another team’s service.
Forwards the request, often adding headers like X-Forwarded-For so the app still sees the real client IP.
Returns the response, maybe gzipping it or caching it.
Useful jobs that collect here:
Job: TLS certificates; Why the proxy, not the app: One place to renew and cipher-suite
Job: HTTP/2 or HTTP/3 at the edge; Why the proxy, not the app: App can stay on simple HTTP/1.1 internally
Job: Buffering slow clients; Why the proxy, not the app: A phone on a bad network does not tie up app threads
Job: Static files; Why the proxy, not the app: nginx serves /assets faster than most app runtimes
Job: Path routing; Why the proxy, not the app: /api vs / without putting that in every service
Job: Basic WAF / IP blocks; Why the proxy, not the app: Drop junk before it hits application code
Load balancing is "pick one of N identical apps." A reverse proxy can do that and everything in the table. So: every load balancer that understands HTTP is a reverse proxy. Not every reverse proxy is used as a multi-server load balancer — some sit in front of one app just for TLS and static files.
A simple example
You run a Django app on port 8000 on an internal network. You do not want that port on the public internet.
nginx listens on 443. It holds the certificate. For /static/ it reads files from disk. For everything else it proxy_passes to 127.0.0.1:8000.
The browser only ever speaks to nginx. Django never deals with certificates. If you later add a second Django worker, nginx's upstream block becomes a small load balancer. Same program, one extra line of config.
That is the usual evolution: reverse proxy first, then reverse proxy + load balancing, then maybe a managed cloud LB in front of several nginx pods.
Common mistakes
Skipping X-Forwarded-For / X-Forwarded-Proto. The app thinks every user is the proxy. Logs, rate limits, and "force HTTPS" all go wrong. Trust those headers only from your proxy, not from the raw internet.
Double-buffering badly. Huge uploads buffered entirely in the proxy can fill disk. Streaming or size limits belong at this layer too.
Using the proxy as a second application server. Heavy Lua or custom logic in nginx can become an undeployable app of its own. Prefer a real API gateway or the app for business rules.
Confusing "hide the app" with "security done." A reverse proxy reduces surface area. It does not replace auth.
How this shows up in real systems
nginx / Caddy / HAProxy / Envoy: software reverse proxies. Envoy is the data plane inside many service meshes (Layer 5).
Cloud HTTP(S) load balancers: reverse proxies as a service.
CDN edges (next posts): reverse proxies in many cities, with a cache.
If a design needs HTTPS, path-based routing, or shielding internal services, you are describing a reverse proxy even if you never say the words.
Recap
A reverse proxy is a front door on the server side: clients hit it, it hits your apps.
It is the natural place for TLS, routing, buffering, and static content.
Load balancers and reverse proxies overlap; an API gateway is this idea with more product features on top.
That is the next post: when the reverse proxy starts acting like a product surface for every API you expose.
Layer 1 · Post 5 of 15
← Previous: Load Balancers → Next: API Gateways
Comments