System Design

Proxy vs Reverse Proxy (Explained with Examples)

Both sit in the middle and forward traffic, but they face opposite directions and serve opposite sides. One protects clients; the other protects servers. Here's the full picture.

By Admin2026-06-1813 min readproxyreverse-proxynetworkingsystem-designsecurityarchitecture

A proxy and a reverse proxy both sit in the middle of a conversation between clients and servers, and both forward requests on behalf of someone. That shared description is why they're constantly confused. But they face opposite directions and serve opposite sides of the conversation: a forward proxy works on behalf of clients, and a reverse proxy works on behalf of servers.

Get this distinction clear and a lot of system design vocabulary falls into place - because reverse proxies are the foundation that load balancers and API gateways are built on. This guide explains both kinds of proxy from the ground up, with concrete examples of each, and a simple memory aid you'll never forget.

What a proxy is, in general

A proxy is an intermediary. Instead of two parties communicating directly, a proxy sits between them and relays the messages. Because it's in the middle, a proxy can do useful things to the traffic passing through - inspect it, filter it, cache it, hide where it came from, or shield what's behind it.

The single question that separates the two types is: on whose behalf does the proxy act?

• A forward proxy acts on behalf of the clients. It sits in front of clients and represents them to the outside world.
• A reverse proxy acts on behalf of the servers. It sits in front of servers and represents them to the outside world.

That's the entire distinction. Everything else follows from it. Let's look at each in turn.

graph LR
    subgraph FWD[Forward Proxy: in front of CLIENTS]
        C1[Client] --> FP[Forward Proxy] --> I1[Internet / Servers]
    end
    subgraph REV[Reverse Proxy: in front of SERVERS]
        I2[Internet / Clients] --> RP[Reverse Proxy] --> S1[Backend Servers]
    end

This diagram contrasts the two proxy types. On top, a forward proxy sits in front of clients: a client sends its requests through the forward proxy out to the internet and servers. On the bottom, a reverse proxy sits in front of servers: clients from the internet reach the reverse proxy, which forwards their requests to the backend servers behind it.

The forward proxy: representing the client

A forward proxy sits in front of one or more clients and forwards their requests out to the internet. When the clients want to reach a server, they don't connect directly - they ask the forward proxy, which makes the request on their behalf and returns the response. From the destination server's point of view, the request came from the proxy, not from the individual client. The client's identity is hidden behind the proxy.

The classic example is a corporate network. A company routes all employee web traffic through a forward proxy so it can control and monitor what leaves the network. This gives the company several capabilities:

• Content filtering and access control. The proxy can block access to certain sites or categories, enforcing the organization's acceptable-use policy. Every outbound request passes through it, so it's the natural enforcement point.
• Monitoring and logging. Because all traffic flows through it, the proxy can log what employees access - useful for security and compliance.
• Caching. If many employees request the same external resource, the proxy can cache it and serve subsequent requests locally, saving bandwidth.
• Anonymity. The destination server sees the proxy's address, not the individual client's, providing a layer of privacy. (This is also how some privacy tools and VPN-like services work - they forward your traffic so the destination doesn't see your real address.)
• Bypassing restrictions. A forward proxy in a different location can make requests appear to originate from there, which is how some tools access region-restricted content.

The common thread: a forward proxy is a tool for the client side. It gives the people running the clients - a company's IT department, a privacy-conscious user - control, privacy, or caching over outbound traffic.

The reverse proxy: representing the server

A reverse proxy sits in front of one or more servers and forwards incoming requests to them. Clients out on the internet think they're talking directly to the server, but they're actually talking to the reverse proxy, which relays their requests to the real backends behind it and returns the responses. From the client's point of view, the reverse proxy is the server. The real servers are hidden behind it.

The classic example is almost any production website. Requests from users hit a reverse proxy first, which then forwards them to the application servers. This gives the organization running the servers several capabilities:

• Security and anonymity for the backends. The real servers' addresses are never exposed to the internet. They sit on a private network, reachable only through the reverse proxy, which shields them from direct attack.
• SSL/TLS termination. The reverse proxy can handle the work of encrypting and decrypting HTTPS traffic, so the backend servers don't have to - and certificates are managed in one place.
• Load balancing. The reverse proxy can distribute incoming requests across multiple backend servers (this is exactly what a load balancer does - a load balancer is a specialized reverse proxy).
• Caching. It can cache responses and serve them directly, reducing load on the backends.
• Compression. It can compress responses before sending them, speeding up delivery to clients.

The common thread: a reverse proxy is a tool for the server side. It gives the people running the servers - the website's operators - security, performance, and the ability to hide and manage their backend infrastructure.

The memory aid

Here's the way to never confuse them again. Both are intermediaries, so focus on which side they hide:

A forward proxy hides the client from the server. A reverse proxy hides the server from the client.

A forward proxy is something you (or your company) set up to control your own outbound traffic - the server you're visiting doesn't know it's there. A reverse proxy is something a website sets up to manage its own incoming traffic - you, the visitor, don't know it's there.

Why this matters for system design

In system design, you'll almost always be dealing with reverse proxies, because you're designing the server side of systems. When you put a load balancer in front of your servers, that's a reverse proxy. When you add an API gateway as the entry point to your microservices, that's a reverse proxy with extra features. When you terminate SSL at the edge or cache responses in front of your application, you're using reverse-proxy capabilities.

This is the key insight that ties it all together: a reverse proxy is the umbrella concept, and load balancers and API gateways are specialized reverse proxies. A load balancer is a reverse proxy focused on distributing traffic; an API gateway is a reverse proxy packed with application-level features. Understanding the reverse proxy as the foundation makes those more specialized components click into place. (We untangle that load-balancer / reverse-proxy / API-gateway relationship in detail in a dedicated comparison.)

Forward proxies, by contrast, are more of a networking and security topic - they show up when discussing corporate networks, privacy, and controlling client-side traffic, rather than in the design of server-side systems.

Interview: If asked the difference, lead with the direction: "A forward proxy sits in front of clients and represents them - like a corporate web filter. A reverse proxy sits in front of servers and represents them - like the front-end of a website. The forward proxy hides the client; the reverse proxy hides the server." Then add the system-design connection: "Load balancers and API gateways are both specialized reverse proxies." That last line shows you understand how the concept fits the bigger picture.

Walking through a forward proxy in action

To make the forward proxy concrete, follow a request. An employee at a company opens their browser and tries to visit a website. Their browser is configured to send all traffic through the company's forward proxy, so:

1. The browser sends the request to the forward proxy instead of directly to the website.
2. The proxy checks its policies - is this site allowed? If the company blocks it, the proxy stops here and returns a "blocked" page; the request never leaves the network.
3. If allowed, the proxy checks its cache - has someone already fetched this recently? If so, it returns the cached copy without going out to the internet at all.
4. Otherwise, the proxy makes the request to the website on the employee's behalf. The website sees the request coming from the proxy's address, not the employee's.
5. The proxy receives the response, optionally logs and caches it, and returns it to the employee's browser.

Notice what the proxy accomplished: it enforced policy, saved bandwidth through caching, logged the activity, and hid the individual employee's identity from the website. All of that is "client-side" value - it benefits the people running the clients.

Walking through a reverse proxy in action

Now the mirror image. A user anywhere on the internet visits a website that uses a reverse proxy:

1. The user's request goes to the website's address, which actually points to the reverse proxy.
2. The reverse proxy receives the request. It may handle SSL/TLS decryption here, so the work is done once at the edge.
3. It checks its cache - if the requested page is cached and still fresh, it returns it immediately, without troubling the backend servers at all.
4. Otherwise, it decides which backend server should handle the request (distributing load across several) and forwards it there.
5. The backend server - whose real address the user never sees - processes the request and returns the response to the reverse proxy.
6. The reverse proxy may compress and cache the response, then returns it to the user.

Here the proxy enforced security (hiding and shielding the backends), improved performance (caching, compression, SSL offload), and distributed load - all "server-side" value benefiting the people running the servers.

More flavors of forward proxy

Forward proxies come in a few varieties worth knowing:

• A transparent proxy intercepts traffic without the client being configured for it or even aware of it - common in corporate and public networks that route all traffic through a proxy automatically.
• An anonymous proxy deliberately hides the client's identifying information from destination servers, used for privacy.
• A high-anonymity proxy goes further, not even revealing that a proxy is being used at all.

These distinctions all live on the client side - they're about how much the proxy reveals about the client to the outside world. Reverse proxies don't have these flavors because their job isn't to hide clients; it's to front and protect servers.

How a reverse proxy hardens security

Security is one of the strongest reasons to put a reverse proxy in front of your servers, and it's worth detailing how it helps. Because every request must pass through the reverse proxy to reach the backends, it becomes a single, controllable chokepoint for defense. The real servers sit on a private network with no direct route from the internet, so an attacker can't address them directly - they can only reach the reverse proxy. The proxy can inspect and filter incoming traffic, block malicious requests, absorb or mitigate certain attacks, and enforce rate limits, all before anything touches the application. It also centralizes TLS, so encryption is handled and certificates are managed in one place. This "one hardened front door, everything valuable behind the wall" arrangement dramatically reduces the attack surface compared to exposing each server directly to the internet.

Common tools

In practice, the same software can serve as either kind of proxy depending on configuration. NGINX, for example, is extremely common as a reverse proxy in front of web applications. Dedicated forward-proxy software and corporate proxy appliances handle the client-side filtering and monitoring role. And cloud services provide reverse-proxy functionality (often bundled with CDN and load-balancing features) as managed offerings. The concept is what matters; many tools can fill either role.

Most production websites of any meaningful size use a reverse proxy for exactly these reasons - it's nearly universal infrastructure. Forward proxies, by contrast, appear mainly in specific contexts: corporate networks that need to control employee traffic, privacy tools, and systems that route outbound requests through a controlled point. If you're designing a typical web system, you'll be working with reverse proxies; forward proxies are something you'll encounter more on the networking and security side than in application architecture.

A note on terminology

One source of confusion worth clearing up: when people say just "proxy," they almost always mean a forward proxy - that's the older, more general usage, the kind that filters or anonymizes client traffic. The word "reverse" was added precisely to name the opposite arrangement. So "proxy vs reverse proxy" is really "forward proxy vs reverse proxy," with "forward" usually left implied. Keeping that in mind helps when you read documentation that says "proxy" and means the client-side kind.

The bottom line

A forward proxy and a reverse proxy are mirror images. Both sit in the middle and relay traffic, but a forward proxy works for the client (hiding and controlling outbound traffic - think corporate filters and privacy tools), while a reverse proxy works for the server (shielding backends and adding security, SSL termination, load balancing, and caching - think the front door of any website).

For system design, the reverse proxy is the one that matters most, because it's the foundation that load balancers and API gateways are built on. Once you see that "hides the client" versus "hides the server" distinction, the confusion disappears for good. We build on this foundation across System Design Fundamentals.

Go deeper

• Proxy server (Wikipedia) - the general concept and its many forms.
• Reverse proxy (Wikipedia) - the server-side proxy in depth.
• What is a reverse proxy? (Cloudflare) - a clear, example-driven explanation.
• What is a forward proxy? (Cloudflare) - the client-side counterpart explained.

More articles