# Reverse proxy vs Forward proxy

> A reverse proxy represents servers to clients; a forward proxy represents clients to destination servers. Choose a reverse proxy to route and protect requests to your services, and a forward proxy to control outbound access from your clients or workloads. They solve different problems and can appear in the same request path.

Source: https://sysround.com/compare/reverse-proxy-vs-forward-proxy
Updated: 2026-11-05


## Side by side

| | Reverse proxy | Forward proxy |
|---|---|---|
| Whom it represents | Servers receiving requests | Clients making requests |
| Typical placement | In front of application services | Between clients and external destinations |
| Destination selection | Maps a service request to a configured backend | Connects to the client's requested destination, subject to policy |
| Common responsibilities | Routing, TLS termination, load balancing, ingress limits | Egress policy, destination filtering, outbound auditing |
| Client configuration | Clients usually use the service's normal URL | Often explicit proxy settings; transparent interception is possible |
| TLS handling | Often terminates TLS; can also pass it through | Often tunnels HTTPS with CONNECT without decrypting it |
| Caching | May cache responses for the services it fronts | May cache eligible responses when HTTP content is visible |
| Security boundary | Restricts access to backends and validates incoming requests | Restricts where clients can connect and what they can send |

## The differences that matter

The distinction is the proxy's role, not the direction packets travel. In client → forward proxy → reverse proxy → backend, the forward proxy acts for the client, while the reverse proxy exposes the destination service. Both relay requests and responses.

A reverse proxy selects a backend using configured rules such as hostname, path, or backend health. This supports routing /images to one service and /api to another, or balancing requests across replicas. A forward proxy instead accepts a client-selected destination and decides whether that outbound connection is permitted.

TLS visibility changes which features are possible. A reverse proxy that terminates TLS can inspect HTTP paths, authenticate requests, and apply application-level limits. A forward proxy tunneling HTTPS with CONNECT generally cannot inspect paths or response bodies. Decrypting that traffic requires TLS interception and client trust configuration, with significant privacy and security implications.

The failure and security concerns differ. A reverse proxy needs healthy backend discovery, bounded queues, connection draining, and protection against spoofed forwarding headers. A forward proxy needs authenticated use, destination restrictions, and controls against access to private networks or metadata endpoints. Either can become a bottleneck or shared failure point, so discuss redundancy and capacity.

## Choose Reverse proxy when

- You need one public service endpoint that routes requests to multiple backend services or replicas.
- You want centralized TLS termination, request-size limits, and ingress rate limiting before traffic reaches application servers.
- You need controlled backend rollout through weighted routing, health checks, and connection draining.
- You want to cache eligible public responses near your service boundary while keeping private responses isolated.

## Choose Forward proxy when

- Workers need outbound internet access, but destinations must be restricted and audited.
- You want external services to see a controlled set of egress IP addresses for allowlisting.
- Managed clients need organization-wide outbound access policies without implementing them separately in every application.
- A crawler needs a centralized point for outbound connection policy, while crawl scheduling still enforces per-site politeness.

## Worked example: A crawler with separate ingress and egress needs

Suppose a crawler has 200 workers making a combined 4,000 outbound requests per second, plus a management API receiving 100 requests per second. Put a reverse proxy in front of the management API to terminate TLS, authenticate operators, and route requests to healthy API replicas. Put a forward proxy on the workers' outbound path to enforce destination policy and record connection metadata. For HTTPS CONNECT tunnels, it cannot cache page bodies or inspect URL paths without TLS interception. Keep per-domain crawl budgets in the scheduler rather than assuming the proxy provides politeness. Size both proxy tiers for connection concurrency and bandwidth, and prevent workers from bypassing the egress policy.

## In the interview

- Name the role before naming a product: 'This reverse proxy fronts our API replicas' or 'This forward proxy enforces worker egress policy.' The same software can support either role.
- Draw the full request path and mark trust boundaries. Expect questions about whether clients can bypass the proxy and reach backends or external destinations directly.
- State where TLS terminates and which component can inspect HTTP content. Interviewers may then probe certificate management, backend encryption, and whether application-level filtering is actually possible.
- Explain high availability, connection limits, timeouts, and overload behavior. For WebSockets or streaming, discuss long-lived connections and draining rather than only requests per second.
- Separate proxy placement from application correctness. Gateway rate limits do not replace transactional inventory checks, and automatic retries do not make non-idempotent operations safe.

## Common mistakes

- Calling a reverse proxy an outbound proxy because it forwards requests. The distinction is whom it represents, not whether it forwards traffic.
- Assuming every reverse proxy load-balances or every forward proxy caches. These are optional capabilities, not definitions.
- Claiming an HTTPS forward proxy can inspect URLs and bodies without explaining TLS interception. A CONNECT tunnel normally leaves that content encrypted.
- Treating proxy placement as a complete security boundary. Prevent bypass, restrict destinations, authenticate access, and trust forwarded identity headers only from known intermediaries.

## Interview questions where it comes up

- [Design a web crawler](https://sysround.com/questions/design-web-crawler): A forward proxy can enforce crawler egress policy, while the design must separately handle destination validation and per-site politeness.
- [Design a distributed rate limiter](https://sysround.com/questions/design-rate-limiter): A reverse proxy is a common enforcement point for ingress limits, prompting discussion of trusted client identity and shared counters.
- [Design a chat app like WhatsApp](https://sysround.com/questions/design-whatsapp): Reverse proxying long-lived chat connections raises questions about routing, connection capacity, idle timeouts, and draining.
- [Design a login and authentication system](https://sysround.com/questions/design-authentication-system): A reverse proxy can terminate TLS and apply coarse abuse controls, but the authentication service must still enforce identity and session correctness.

## FAQ

### What is the main difference between a reverse proxy and a forward proxy?

A reverse proxy represents destination servers and routes requests to their backends. A forward proxy represents requesting clients and connects to destinations on their behalf. The key distinction is which side the proxy serves, not the direction of network traffic.

### Is a load balancer a reverse proxy?

An HTTP load balancer that accepts requests and forwards them to backend servers acts as a reverse proxy. Load balancing is one possible reverse-proxy function, alongside TLS termination, routing, and caching. Not every load-balancing mechanism is an HTTP reverse proxy; DNS-based balancing, for example, does not relay requests.

### Can you use a forward proxy and a reverse proxy together?

Yes. A workload can send an outbound request through its organization's forward proxy, which then connects to a destination's reverse proxy. Each enforces a separate policy: the forward proxy controls client egress, while the reverse proxy controls access to destination services.

## Related concepts

- [Reverse proxy](https://sysround.com/concepts/reverse-proxy)
- [Load balancing](https://sysround.com/concepts/load-balancing)
- [API gateway](https://sysround.com/concepts/api-gateway)
- [TLS and HTTPS](https://sysround.com/concepts/tls)
- [Access control and RBAC](https://sysround.com/concepts/access-control)


---
SysRound (https://sysround.com) is an AI practice tool for system design interviews: a voice or typed AI interviewer, a shared whiteboard, then feedback on every skill and a model answer. Its feedback is AI-generated and can be wrong.