Proxies (Forward & Reverse)

A proxy mediates between a client and a server. A forward proxy acts on behalf of the client (think: corporate web proxy, VPN). A reverse proxy acts on behalf of the server (think: Nginx in front of your app servers, where load balancer, API gateway, CDN edge are all reverse proxies).

Different problems for each direction. Forward proxies provide content filtering, caching, anonymization, or access control for clients in a network. Reverse proxies provide load balancing, TLS termination, caching, auth, and abstraction in front of backend services.

Forward proxy: client is configured to send requests through the proxy, which forwards them to the destination. Reverse proxy: clients hit a single address; the reverse proxy routes the request to one of many backend servers based on URL, headers, or load.

• Reverse proxy: hides backend topology, terminates TLS once, centralizes routing
• Forward proxy: enforces policy uniformly for a population of clients
• Both can cache, both can rewrite, both can authenticate

• Extra hop adds latency
• Reverse proxy is a SPOF unless run in a fleet
• Misconfigured proxies leak client IPs, break TLS, or open security holes

• URL Shortener →

  API Gateway is a reverse proxy with auth + rate-limiting

• API Rate Limiter →

  Edge proxy IS a reverse proxy that runs rate-limit checks

• Netflix →

  Zuul is a reverse proxy for control-plane traffic; CDN edges are reverse proxies for video bytes

• Reverse proxies are everywhere: load balancers, API gateways, CDN edges, sidecars (Envoy). Same pattern, different roles.
• TLS termination at the proxy means downstream traffic is plaintext (in the trusted network). Use mTLS if you need encryption all the way through.
• Forward proxies leak less than you think; many sites detect proxy headers and treat them differently.