Proxies & Gateways
Load Balancing covers how traffic is spread across a pool and where (L4 versus L7) that decision gets made. This page is about a different question: whose side a middlebox is on. A proxy always sits between two parties, but who it represents - the client, the server, or the operator of a whole fleet of services - changes what it is called and what problem it solves.
Forward proxy: acts on behalf of the client
A forward proxy sits in front of a group of clients and makes requests to the internet on their behalf. The destination server sees the proxy's IP, never the client's - the proxy hides the client from the outside world.
- Client-configured - the client (or its network) is explicitly set to send
all traffic through the proxy, e.g. a corporate laptop pointed at
proxy.corp.internal:8080. The client knows the proxy exists. - Transparent - the network intercepts traffic without any client configuration, usually at a router or gateway. The client believes it is talking directly to the internet.
Forward proxies are used to enforce outbound policy: block access to certain sites, log what employees request, cache common downloads for a whole office, or let anonymized traffic egress from a single, controlled IP.
Reverse proxy: acts on behalf of the server
A reverse proxy sits in front of a server (or pool of servers) and accepts requests on their behalf. The client thinks it is talking to the real service; it never sees which backend actually answered - the proxy hides the server from the outside world. A load balancer is one flavor of reverse proxy; so is a TLS-terminating edge that decrypts HTTPS before handing plain HTTP to backends.
| Forward proxy | Reverse proxy | |
|---|---|---|
| Represents | The client | The server |
| Hides | Client identity from the destination | Server identity/topology from the client |
| Client awareness | Configured or transparent | Client is unaware a proxy exists at all |
| Typical use | Content filtering, egress control, client caching | TLS termination, load balancing, edge caching |
Same shape, opposite side. If you remember only one thing: a forward proxy protects clients from the internet, a reverse proxy protects servers from clients.
API gateway: a reverse proxy with policy
An API gateway is a reverse proxy purpose-built for sitting in front of a set of backend services rather than one pool of identical servers. It is the single edge that every external request passes through before reaching anything internal, and it centralizes work every service would otherwise have to duplicate:
- Authentication - verify an API key, JWT, or session token once, at the edge, instead of in every service.
- Rate limiting - cap how many requests a client or key can make per window, protecting backends from being overwhelmed by one noisy caller.
- Request routing - send
/users/*to the users service,/orders/*to the orders service, based on path, host, or header - the same kind of L7 decision described in Load Balancing, but routing to different services instead of different replicas of the same one. - Aggregation - fan a single client request out to several backend services and combine their responses, so a mobile client makes one round trip instead of five.
A gateway turns "many services, many edges" into "many services, one edge," which is also why it becomes a single choke point: if it is down, every service behind it is unreachable, no matter how healthy they are.
Service mesh: proxies between services
Gateways guard the edge - traffic entering the system from outside. Once a request is inside, it typically fans out into many service-to-service calls, and those need the same policy applied internally: encryption, retries, observability. A service mesh does this by attaching a small proxy - a sidecar - to every service instance, so all traffic in and out of that instance passes through its sidecar first.
Envoy is the proxy most meshes (Istio, Linkerd's predecessor design, AWS App Mesh) are built on. With a sidecar next to every instance:
- mTLS between services - each sidecar holds a certificate and encrypts traffic to other sidecars, so every internal call is authenticated and encrypted without the application code touching TLS at all.
- Traffic shaping - the mesh can shift 5% of traffic to a new version for a canary release, inject artificial latency to test resilience, or retry a failed call to a different instance, all as configuration rather than code changes in each service.
The sidecar pattern means every service gets this for free just by being deployed into the mesh - the proxy is identical everywhere, only its configuration differs per route.
A sidecar per instance means a proxy hop on every single service-to-service call. That buys uniform security and control, but it is not free: expect single-digit milliseconds of added latency and real memory/CPU overhead multiplied across every instance in the fleet.
Recap
- A forward proxy represents the client and hides it from the destination; a reverse proxy represents the server and hides it from the client.
- An API gateway is a reverse proxy in front of many services, centralizing auth, rate limiting, routing, and aggregation at one edge.
- A service mesh pushes proxies (sidecars) between services themselves, giving every internal call mTLS and traffic-shaping controls for free.
- Edge proxying and mesh proxying solve different layers of the same problem: who gets in, versus how traffic behaves once it's inside.