The terms “forward proxy” and “reverse proxy” describe fundamentally different architectural patterns, yet they both use the word “proxy” and both sit between clients and servers. The confusion is understandable, but the distinction matters when designing systems, debugging connectivity issues, or evaluating security posture.

Forward Proxies Represent the Client

A forward proxy acts on behalf of clients. When a user’s browser connects to a forward proxy, the proxy makes outbound requests to arbitrary destinations on the internet using the proxy’s own IP address. The destination server sees the proxy, not the original client.

The classic use case is corporate network egress. Employees’ devices send all HTTP requests through a forward proxy, which enforces acceptable use policies, inspects traffic for malware, and logs activity. The proxy reaches out to any destination the client specifies, whether that’s a news site, a SaaS application, or a package repository.

Forward proxies typically require client-side configuration. The browser or operating system must be told to use the proxy, either through explicit settings or via auto-configuration protocols like WPAD. The client is aware it’s using a proxy and deliberately routes traffic through it.

Reverse Proxies Represent the Server

A reverse proxy acts on behalf of servers. It accepts inbound connections from clients on the internet and forwards those requests to a specific set of backend servers. Clients connect to what appears to be the destination service, unaware that a proxy is intermediating.

The most common use case is load balancing and application delivery. A reverse proxy receives requests for api.example.com, terminates TLS, and distributes requests across a pool of application servers. It may also handle caching, compression, rate limiting, and request routing based on URL paths or headers.

Clients don’t configure reverse proxies. From the client’s perspective, the reverse proxy is the service. There’s no difference between connecting to a single server directly and connecting to a reverse proxy fronting multiple servers. The topology is invisible.

Why Both Are Called Proxies

Both patterns involve an intermediary that forwards network traffic. The “forward” and “reverse” terminology refers to directionality relative to the client-server relationship and which side initiates the deployment.

A forward proxy is deployed by the client side (or their network administrator) to control and mediate outbound connections. The client explicitly uses it to reach arbitrary external servers.

A reverse proxy is deployed by the server side (or their infrastructure team) to control and mediate inbound connections. The server operator places it in front of their own infrastructure, and clients connect to it without realizing it’s there.

The same software can often operate in either mode. Nginx, HAProxy, and Envoy are all commonly deployed as reverse proxies, but can be configured to function as forward proxies. Squid is traditionally a forward proxy but supports reverse proxy configurations. The distinction is architectural intent, not implementation.

The Middle Ground: Transparent Proxies

Transparent proxies muddy the waters further. These operate as forward proxies without requiring client configuration. Network-level routing (typically via policy-based routing or interception at a gateway) silently redirects traffic through the proxy. The client believes it’s connecting directly to the destination, but the network intercepts and proxies the connection.

ISPs sometimes deploy transparent proxies for caching or traffic shaping. Enterprise networks use them for inspection without requiring endpoint configuration. From a functional perspective, they’re forward proxies—they reach arbitrary destinations on behalf of clients—but from the client’s perspective, they’re invisible like reverse proxies.

Why the Distinction Matters

The architectural difference has practical implications:

Security boundaries differ. Forward proxies inspect and control traffic leaving a trusted network. Reverse proxies protect backend infrastructure from untrusted inbound connections. The threat models and security controls are opposite.

Configuration lives in different places. Deploying a forward proxy requires touching client devices or network configuration. Deploying a reverse proxy requires changes only on the server side.

Performance characteristics diverge. Forward proxies add latency to every outbound connection and become a chokepoint for egress traffic. Reverse proxies are typically deployed in a scale-out configuration with minimal per-request overhead.

Debugging requires different approaches. Connection failures through a forward proxy require checking client proxy settings and proxy logs. Connection failures to a reverse proxy require investigating DNS, firewall rules, and backend health.

Understanding which pattern you’re working with clarifies where to look when things break and how to reason about the dataflow in your system.