Both a forward proxy and a reverse proxy sit between a client and a server and relay traffic. What actually distinguishes them — which side deploys and configures each, and what does each one hide from the other side?

## Same machinery, opposite loyalties A proxy is any intermediary that accepts a connection from one party and makes its own connection to another party on someone's behalf. A forward proxy and a reverse proxy both do precisely that, with the same sockets and often the same software. What separates them is **whose agent the box is**, and every practical difference follows from that single fact. A **forward proxy** works for the *client population*. Somebody on the client side — an IT department, a build environment, a developer's tooling — decides that outbound traffic goes through it. The origin server is not consulted and usually cannot tell; it just receives a connection from the proxy's address. A **reverse proxy** works for the *service owner*. The client resolves `app.example.com`, connects to whatever address that name points at, and that address belongs to the proxy. The client normally cannot tell a proxy is involved at all, and that opacity is the entire point. ## Who configures it This is the fastest way to classify a box in a real system. A forward proxy has to be *told to the client*: browser or OS proxy settings, a PAC file, the `HTTP_PROXY`/`HTTPS_PROXY` environment variables that most HTTP libraries and CLIs honour, or a per-invocation flag such as curl's `-x`. A reverse proxy is configured by the *service*: it is what DNS points at, and the client's configuration says nothing about it. ```bash # forward proxy: the CLIENT is configured curl -x http://proxy.corp.internal:3128 https://api.example.com/health # reverse proxy: nothing on the client says "proxy" curl https://app.example.com/health ``` ## What each one hides A forward proxy **hides clients from servers**. A thousand workstations appear to the internet as one egress address — convenient when a partner wants to allowlist you, and inconvenient when a rate limiter upstream counts you as one very busy client. It also gives the client side a control point: category and destination allowlists, auditing of who reached what, shared caching of large downloads, and credential injection for outbound calls. A reverse proxy **hides servers from clients**. It conceals how many backends there are, what addresses and ports they listen on, which instance served this request, and whether they even speak the same protocol version the client used. That concealment is what buys you freedom: you can terminate TLS at the edge, add compression or caching, split traffic by path onto two different services, or replace the backend entirely, and no client changes. ## Two connections, not one The most consequential detail, and the one candidates skip: the client's TCP connection — and its TLS session, if the proxy terminates TLS — **ends at the proxy**. The proxy then opens a *separate* connection to the backend. ``` client ──TLS──▶ reverse proxy ──plain HTTP──▶ backend (connection 1) (connection 2) ``` Everything that was a property of connection 1 — the peer address, the negotiated TLS and any client certificate, sometimes the protocol version and the host the user typed — is now merely information the proxy may *choose* to carry across as data. Nothing about connection 2 reveals it automatically. That single fact explains a family of production surprises: application logs that show one internal address for every request; rate limiting and IP allowlists that suddenly apply to the whole world at once; an app that believes it was called over plain HTTP when the user typed `https://`; and session logic keyed on client address that starts behaving oddly. The remedy is always the same shape — the proxy must forward the missing facts explicitly, and the backend must only believe them when they come from that proxy. ## The interception case A third arrangement confuses people: the *transparent* or *intercepting* proxy, where traffic is redirected to a proxy at the network layer without the client ever being configured. In role it is still a forward proxy — it acts for the client side and hides clients from servers — but the client did not opt in and its software may not even know. That distinction matters when things break: an unconfigured client will not fall back or report a proxy error the way a configured one does. ## Where load balancers and gateways fit Both are reverse proxies with an emphasis on a particular job. Any argument about whether a box is "a load balancer or a reverse proxy" is usually an argument about vocabulary, not architecture, and it is worth resolving by asking which responsibilities you want at that hop. ## What interviewers actually probe The definitional half is the warm-up. The real follow-up is nearly always *"so how does your application still see the real client?"* — because that is where the two-connection model stops being trivia and starts being the reason a redirect loops, an allowlist fails open, or an abuse report names the wrong address.