Hide outline
Feedback
Guide
Was this lesson helpful?
Dive Deeper
Generate a follow-up sub-lesson on any aspect of this topic
Guide complete
Forward Vs. Reverse Proxies In Practice
Generate a follow-up sub-lesson on any aspect of this topic
Forward Vs. Reverse Proxies In Practice
TLDR;
- If the company wants one place to enforce browsing policy for 50 laptops, the proxy sits on the client side.
- If the web app needs one public endpoint while servers scale in and out, the proxy sits on the server side.
- If encryption and identity move into every hop, proxy placement shifts toward where trust is managed.
A proxy is an intermediary that relays web requests so many clients can share control, caching, and visibility that a direct client to server connection cannot provide consistently. In a small office network, imagine 50 laptops browsing the public web. With direct browsing, each laptop opens its own HTTP connection to each origin site, and any rule like blocking social media or caching common downloads must be repeated on every machine. That is the constraint that pushes us to insert a single box in the path instead of changing 50 endpoints. Let’s ground the baseline path first:
In the baseline, the client talks straight to the origin server across the internet, and the office network is just a shared pipe. The key detail is that the origin server sees the client’s IP and headers directly, and policy lives at the edge of each laptop. Once we add an intermediary, we are deciding who configures that intermediary and whose identity it presents to the other side.
A forward proxy is a client-configured intermediary that sends requests on behalf of the client to the public internet. Each laptop either sets an explicit proxy setting or is forced through it by the office network, and the request path becomes client to forward proxy to origin. From the origin’s perspective, the forward proxy is the caller, so the origin typically sees the proxy’s IP address as the source and not the individual laptop. This placement is what enables the office to apply one set of egress rules and one shared cache to many clients, without requiring any cooperation from the public websites. Here is the forward proxy in the request path:
The diagram’s moving part is configuration control. The clients are the ones that opt into the proxy through settings or network enforcement, while the origin server is unaware of the office topology and just responds to a single apparent requester. That mismatch is useful when the office wants privacy for clients, consistent filtering, or caching of repeated downloads like OS updates.
Rule of thumb
If the proxy is chosen by the client side and the internet sees the proxy, it is forward.
A reverse proxy is a server-managed intermediary that receives public requests and forwards them to one of several upstream application servers. The client connects to a single public endpoint, usually via DNS pointing a hostname like app.example.com at the reverse proxy. The request path becomes client to reverse proxy to upstreams, and the upstream servers can sit on private subnets and change over time without the client knowing. This placement is what lets one team centralize internet-facing concerns like TLS termination and routing while leaving application code focused on business logic. Here is the reverse proxy in the request path:
The diagram’s key change is what the client thinks it is talking to. The client still believes it is talking to the app, but it is actually talking to the reverse proxy as the stable front door. The reverse proxy then selects an upstream target and can terminate TLS, meaning it decrypts HTTPS at the edge and forwards plain HTTP or re-encrypted traffic internally depending on the trust boundary.
The clean way to distinguish these proxies is to name which side they represent and who controls the configuration. If clients must be configured to use it, it is representing clients, and if servers are placed behind it, it is representing servers. DNS is a practical clue. When app.example.com resolves to the proxy and every client in the world uses that address, it is almost always a reverse proxy. When an office laptop has a proxy setting or a managed network that forces traffic through an egress box, it is almost always a forward proxy. Check your intuition against a few short scenarios:
In the checkpoint scenarios, the deciding signals are ownership and representation. Client-managed configuration, per-user policy, and hiding many clients behind one visible requester point to forward. A single public hostname, upstream pools, and server-side operational ownership point to reverse.
Forward proxies commonly exist because an organization cares about what leaves its network. Typical responsibilities cluster into a few repeatable jobs.
The main tradeoff is visibility versus end-to-end encryption. If clients use HTTPS directly to origins, the proxy cannot inspect the content unless the organization performs TLS interception, which changes the trust model and increases operational and compliance burden. Even without interception, the proxy still adds latency and can become an outage point for all browsing if it fails closed. Scan how these attributes vary across use cases:
The scan is meant to make the tradeoffs explicit. Forward proxies score well on centralized ownership and consistent egress policy, but they push against end-to-end privacy when deeper inspection is required, and they concentrate failure risk into one outbound chokepoint.
Practical caveat
A forward proxy that cannot see inside TLS still controls destinations, not page contents.
Reverse proxies commonly exist because a service wants one durable front door while the backend fleet changes. Their responsibilities are mostly server-side concerns that scale better when centralized in one layer rather than re-implemented in each microservice.
The key tradeoff is that a reverse proxy becomes part of your availability story and your trust boundary story. A single reverse proxy can be a single point of failure unless it is deployed redundantly, and it often sets headers like X-Forwarded-For to preserve the original client IP for logs and auth decisions. Upstreams must only trust those headers when they are sure requests came through the proxy, otherwise any direct caller could spoof them. Here are the common blocks and what they buy and break:
The building blocks highlight that reverse proxies simplify application code by moving cross-cutting concerns into one layer, but they also centralize configuration risk. A bad routing rule, an overly aggressive rate limit, or a mistaken cache key can affect all downstream services because the proxy is on every request path.
Reverse proxies appear in most modern architectures because they stabilize the public interface while letting teams change everything behind it. A monolith can sit behind a reverse proxy to terminate TLS and compress responses. A microservices setup often puts a reverse proxy or API gateway in front to route requests to multiple services and to enforce shared policies. Even serverless backends typically sit behind a managed edge that behaves like a reverse proxy, mapping a stable hostname to shifting compute. Compare the two common shapes directly:
In the comparison, the stable public endpoint and centralized certificate management are the biggest practical wins. The backend can scale horizontally, roll deployments, or move subnets without changing client configuration. You might skip a reverse proxy for a simple internal service where clients are on the same trusted network and the service is not internet-facing, but as soon as the service becomes public, the internet-facing responsibilities tend to reappear somewhere.
In the office browsing scenario, a forward proxy is defensible when the organization needs client-side control like egress allowlists, per-user browsing policy, or bandwidth savings from shared caching. The proxy belongs on the path out of the office network because that is where the organization owns both the clients and the network, and it can enforce policy without asking every public origin server to participate. In the public web app scenario, a reverse proxy is defensible when the service needs one stable endpoint while the app servers scale, deploy, and fail independently behind it, and when TLS termination and routing should be handled once rather than repeated in every application process.
The redesign trigger is a shift in where trust and identity must live. If you adopt zero-trust networking where every hop is mutually authenticated, or you require true end-to-end encryption where intermediaries must not decrypt, then policies that assumed visibility at the proxy may need to move to endpoints or into a service mesh sidecar closer to each workload. When that happens, keep the original question as the anchor. Which side needs the proxy to represent it, and who can safely control its configuration.