What is a reverse proxy? (And when login belongs in front)
A server that faces the internet so your real servers don't: TLS, load balancing, caching, and in identity-aware setups, authentication itself. How the headers work and what makes it safe.
A reverse proxy is a server that sits in front of other servers and handles the internet on their behalf: clients connect to the proxy, and the proxy forwards each request to the right backend. Cloudflare’s definition is the standard one: “a server that sits in front of web servers and forwards client (e.g. web browser) requests to those web servers.” The word reverse marks which side it protects: a forward proxy fronts clients (your office’s outbound proxy), a reverse proxy fronts servers: no client ever talks to the origin directly.
Why they’re everywhere
Because one machine at the front can do jobs every backend would otherwise repeat. It can terminate TLS (decrypt incoming traffic once, sparing the origin the computation), balance load across several servers, cache responses, and hide the origin’s IP address entirely, which, as Cloudflare notes, “makes it much harder for attackers to leverage a targeted attack,” DDoS included. Nearly every site of any size sits behind one; if you’ve deployed anything behind nginx, Caddy, or Cloudflare itself, you’ve run one.
The headers underneath
Proxying isn’t passive relaying: the proxy rewrites the conversation. nginx, for instance, redefines the Host and Connection headers on the way through and lets you set or strip anything else. The best-known proxy header is X-Forwarded-For: since the backend now sees every request arriving from the proxy’s IP, each hop appends the address it saw, preserving who originally connected. MDN’s warning about it is the load-bearing sentence of this whole topic: security decisions “must only use IP addresses added by a trusted proxy”. Anyone can put whatever they like in a header before the request ever reaches you. Headers are trustworthy exactly as far as you control the machine that set them.
The identity-aware proxy: auth at the front door
Push that idea one step and you get the pattern behind modern private dashboards: the proxy doesn’t just forward. It authenticates. The user signs in at the proxy (OAuth, OIDC, whatever), and the proxy injects a header naming the verified identity; the backend accepts that header only from the proxy’s IP and trusts it as login. OpenClaw supports exactly this as a first-class Gateway mode (trusted-proxy), and its docs are refreshingly stern about the two conditions that make it safe: the backend must verify the request came from a listed trusted proxy, and the proxy must overwrite, not append every identity-adjacent header a client could supply. Get either wrong and the front door’s lock is decorative, which is why OpenClaw’s own security audit deliberately flags the mode as critical-severity, a standing reminder that you’ve delegated authentication to your proxy setup.
When a reverse proxy is the wrong tool
The pattern assumes the proxy is the only way in. If the backend is also reachable directly (a forgotten open port, an internal network path), the trust model is void; MDN puts it flatly for X-Forwarded-For, and OpenClaw’s docs list “any path to the Gateway that bypasses the proxy” as a disqualifier. So a reverse proxy belongs in front of services that must serve many people on the open internet. For a service only you need to reach, not exposing it at all beats authenticating it well: keep it loopback-only and come in over SSH or a private tunnel instead. The reverse proxy is how you do a public front door properly. The quieter option is not having one.