Forward and Reverse Proxies

A proxy is not a router. A router forwards IP packets without ending the connection; a proxy terminates a TCP (usually also TLS) connection from one side, reads the bytes as an application protocol, and opens a second connection to the other side. The two connections have different source addresses, different TCP state, possibly different HTTP versions, and independent lifetimes. Everything a proxy can do — cache, rewrite, route, buffer, compress, inspect — follows from the fact that it holds a complete request in its own memory between the two connections.

That also tells you what a proxy costs: one extra hop of latency (tens of microseconds in the same rack, a full RTT if it is elsewhere), one extra place to run out of file descriptors or ports (see The Connection Lifecycle: Close, Reset, TIME_WAIT, CLOSE_WAIT for TIME_WAIT on the proxy side), and one extra timeout that has to agree with the timeouts on either side of it.

A forward proxy sits on the client’s side of the network and speaks to the outside world on the client’s behalf. The client is configured to use it (HTTP_PROXY=http://proxy.corp:3128, a PAC file, or a browser setting) and knows it exists. Uses: egress control (only the proxy is allowed through the firewall, so every outbound request is logged and filterable), caching shared across many clients, anonymity (the origin sees the proxy’s address), and policy — the corporate filter that blocks a domain category.

For plain HTTP the client sends the full URL in the request line (GET http://example.com/ HTTP/1.1) and the proxy fetches it. For HTTPS the client sends CONNECT example.com:443 and the proxy becomes a blind TCP tunnel: it sees the hostname (from the CONNECT line) but nothing inside the TLS session. A corporate proxy that wants to inspect HTTPS content must install its own CA on every client and re-sign certificates — the Certificates and the Chain of Trust chain of trust deliberately makes that impossible without the client’s cooperation.

Squid is the classic forward proxy; Envoy and nginx can be configured as one; the sidecar in a service mesh acts as a forward proxy for outbound traffic from its pod.

A reverse proxy sits in front of server infrastructure and is, from the client’s point of view, the server. DNS for api.example.com resolves to the proxy; the client has no way to know there is anything behind it. nginx (proxy_pass), HAProxy, Envoy, Traefik and Caddy are reverse proxies; so is every cloud load balancer that terminates HTTP.

What a reverse proxy takes off the application: TLS termination (one place holds the certificate and the CPU cost of handshakes — see The TLS Handshake); routing (/api/* to one pool, /static/* to another, by Host header or path); caching and compression of responses; and buffering slow clients — nginx reads the whole upstream response into its own buffer and frees the application worker immediately, then drips it to a slow phone link over the next seconds. Without that, a 3G client holds an application thread for the entire transfer (What Happens When the Receiver Is Slow).

It also changes what the application sees. The TCP peer is the proxy. The request may have been HTTP/2 or HTTP/3 on the outside and is HTTP/1.1 on the inside. The scheme may have been https outside and http inside. Anything the application needs to know about the original client has to be carried in headers — which is where trust breaks.

A transparent proxy intercepts traffic without the client being configured for it: a firewall rule (iptables -t nat -j REDIRECT) or a policy route steers port 80/443 into a local proxy process. ISPs and hotel networks did this to HTTP for years; service meshes do it today — Istio’s init container installs REDIRECT rules so every connection from the pod passes through the Envoy sidecar without the application knowing. Transparent HTTPS interception without a trusted CA can only tunnel, not read.

Because the upstream sees the proxy’s address, proxies annotate the request. X-Forwarded-For: client, proxy1, proxy2 — each hop appends the address it saw. X-Forwarded-Proto: https says what the client originally used. Forwarded: for=203.0.113.9;proto=https;by=10.0.3.7 is the standardized form (RFC 7239). Via: 1.1 edge-cache-7 names the proxy and the HTTP version it spoke, mostly for loop detection.

The trust problem: the client can send any of these headers itself. curl -H "X-Forwarded-For: 127.0.0.1" reaches an application that trusts the leftmost value and now believes the request is local. The only sound rule is: trust exactly the hops you operate, counted from the right. nginx expresses this as set_real_ip_from 10.0.3.0/24; real_ip_header X-Forwarded-For; real_ip_recursive on;; Express as app.set("trust proxy", 1) (trust one hop). Rate limiters, audit logs and IP allow-lists that read the leftmost value are the classic vulnerability.