What a reverse proxy is and when you need one

A proxy is anything that makes requests on someone else’s behalf. A forward proxy sits in front of clients (a company proxy that all browsers in the office go through). A reverse proxy sits in front of servers: the browser talks to the proxy, believing it is the website, and the proxy quietly passes the request on to one or more applications behind it and returns the answer.

browser  --->  https://app.example.com  (reverse proxy: Nginx, Caddy, Traefik)
                        |
                        +--->  http://127.0.0.1:3000   (Node app)
                        +--->  http://127.0.0.1:8000   (Python API, /api/*)
                        +--->  /var/www/static          (files)

Nginx, Caddy, Traefik, HAProxy and Apache httpd with mod_proxy are all used this way. Cloud load balancers and CDNs are reverse proxies too, just run by someone else.

Why put one in front of your app

• HTTPS in one place. The proxy holds the certificate, speaks TLS to the browser and plain HTTP to your app on localhost. Your app never touches certificates, and renewing them is the proxy’s job.
• One address, many apps. Route by host name (api.example.com to one process, www to another) or by path (/api/ to the backend, everything else to the frontend). Only ports 80 and 443 are open to the world.
• Static files served fast. Web servers are very good at sending files. Let the proxy serve images, CSS and JavaScript so the application only handles real requests.
• Load balancing and zero-downtime deploys. Point the proxy at two or more copies of the app. Restart one while the other keeps serving.
• A place for cross-cutting rules. Redirects, security headers, compression, rate limiting, request size limits, access logs, IP allow lists and basic auth belong in the proxy, written once, instead of in every application.
• Hiding the internals. The browser sees one server. Which port the app listens on, which language it is written in and whether it just restarted are not visible.

What the application sees

Because the app receives the request from the proxy, not the browser, the client’s address appears to be 127.0.0.1 and the scheme appears to be http. The proxy fixes this by adding headers, and the application must be told to trust them:

• X-Forwarded-For: the real client IP address (and any earlier proxies).
• X-Forwarded-Proto: https, so the app generates correct absolute links and secure cookies.
• X-Forwarded-Host or a preserved Host header: the host name the browser asked for.
• The newer standardized Forwarded header carries the same information in one field; most frameworks still read the X-Forwarded ones.

Frameworks have a switch for this: Express has app.set('trust proxy', 1), Django has SECURE_PROXY_SSL_HEADER and USE_X_FORWARDED_HOST, Rails and Laravel have trusted proxy settings, Go’s net/http leaves it to you. Only trust these headers when the app is genuinely reachable solely through the proxy; otherwise anyone can forge their IP.

When you do not need one

• A platform already provides it: Heroku-style hosts, Vercel, Netlify, Cloud Run, Kubernetes Ingress and most managed app services put their own proxy in front of you. Adding your own is redundant.
• A single service, on an internal network, where plain HTTP is acceptable and there is nothing else to route to.
• Local development. Run the app directly; add the proxy when you deploy, or run it in Docker Compose to mimic production.

Choosing one

• Caddy: automatic HTTPS, a configuration that fits on a napkin. Best for small servers and people who do not want to think about certificates.
• Nginx: the most common choice on Linux servers, extremely fast, huge amount of documentation and examples. Certificates via Certbot.
• Traefik: discovers Docker containers and Kubernetes services and routes to them from labels, so you rarely write a route by hand. Natural fit for container hosts.
• HAProxy: load balancing first; the choice for high-traffic TCP and HTTP balancing.
• Apache httpd: still everywhere, especially on shared PHP hosting, with .htaccess files and a module for everything.

Official documentation

• Proxy servers and tunneling on MDN
• Nginx ngx_http_proxy_module
• Caddy reverse_proxy directive