Forward Proxy vs Reverse Proxy

The Core Distinction

Both types of proxy are intermediaries that sit between two parties and forward traffic. The difference is which party they represent and which they hide.

A forward proxy represents the client. The client points its traffic at the proxy; the proxy forwards requests to the internet; the destination server sees the proxy, not the client. The client's identity is protected from the outside world.

A reverse proxy represents the server. Clients connect to the reverse proxy thinking it is the server; the proxy forwards requests to one or more backend servers; the client never directly touches the backend. The server's identity and infrastructure are protected from the outside world.

Same mechanism — interception and forwarding — applied in opposite directions for opposite purposes.

Forward Proxy: Representing the Client

A forward proxy must be explicitly configured on the client side (or the network must intercept traffic transparently). Once configured, all requests flow through it before reaching the internet.

Corporate content filtering is one of the most common deployments. An organization routes all employee web traffic through a forward proxy that inspects requests, blocks access to prohibited categories, and logs activity for compliance purposes. Employees may not even be aware of the proxy — their network is configured to route all HTTP and HTTPS traffic through it automatically.

Anonymity and geo-bypass are the consumer-facing use cases. By routing traffic through a proxy in another country, users can appear to originate from that location. This has legitimate uses (accessing region-restricted research resources) and enforcement challenges for content providers.

Caching was historically important when bandwidth was expensive. ISPs deployed forward caching proxies that stored popular content — a second request for the same large file would be served from the proxy's local cache rather than re-fetching it across expensive international links.

Reverse Proxy: Representing the Server

A reverse proxy is deployed by the server operator, not the client. Clients connect to it as if it were the real server — they do not know or care that a proxy is involved. The reverse proxy's IP is in DNS; clients connect to it; it decides what to do with each request.

Load balancing is the most common use case. A single domain name resolves to one reverse proxy, which distributes incoming requests across a pool of backend application servers. If one backend fails, the proxy stops routing to it. As traffic grows, new backends are added to the pool without any client-visible change.

TLS termination offloads the cryptographic overhead of TLS from application servers. The reverse proxy handles the TLS handshake, decrypts the request, and forwards plain HTTP to backends over the internal network. Backends only need to handle application logic, not certificate management.

Static asset caching lets the reverse proxy serve images, CSS, and JavaScript directly from its cache without hitting the application server at all — similar to how a CDN works but at a single-site scale.

DDoS and bot protection at the edge: reverse proxies can inspect requests, rate-limit IPs, block known malicious patterns, and require CAPTCHA challenges before passing traffic to the origin.

Side-by-Side Comparison

TLS Termination: Why Reverse Proxies Handle HTTPS

When a reverse proxy terminates TLS, it decrypts HTTPS traffic at the edge and communicates with backends over plain HTTP (or re-encrypted HTTPS) on the internal network. This pattern has several advantages: the TLS certificate and private key live in one place (the reverse proxy) rather than on every backend server, backends can be simpler application processes without TLS configuration, and the proxy can inspect and modify plaintext requests before forwarding them.

The internal traffic between reverse proxy and backends is typically considered trusted because it stays within a private network or VPC. If internal security is a concern, the proxy can re-encrypt traffic to backends — a pattern called TLS passthrough or end-to-end TLS.

Frequently Asked Questions

What is a forward proxy?

An intermediary that forwards client requests to the internet. The destination sees the proxy's IP. Used for anonymity, content filtering, and caching — configured by the client or the client's network.

What is a reverse proxy?

An intermediary that forwards inbound requests to backend servers. Clients connect to it as if it were the real server. Used for load balancing, TLS termination, caching, and DDoS protection — deployed by the server operator.

What are examples of reverse proxies?

Nginx, HAProxy, Apache mod_proxy, Caddy, Traefik, and cloud services like Cloudflare, AWS CloudFront, and Google Cloud Load Balancing. Most CDNs are reverse proxies operating at global scale.

Does a reverse proxy hide the server's IP?

Yes, if configured correctly. When clients only know the proxy's IP, the origin server's address stays private. CDNs use this pattern to protect origins from direct attack — if the origin IP leaks, attackers can bypass the CDN entirely.

Is Nginx a reverse proxy?

Yes. Nginx is commonly deployed in front of application servers to handle TLS, serve static files, and proxy dynamic requests to backends. It also supports forward proxy configuration.

What is the difference between a reverse proxy and a load balancer?

A load balancer distributes traffic across backends — that is its primary job. A reverse proxy is a broader concept: it includes TLS termination, caching, compression, and request routing in addition to load distribution. Many reverse proxies include load balancing; dedicated hardware load balancers may not include the other proxy features.