Proxy

A proxy is a server that relays traffic between two endpoints instead of letting them talk directly. The client sends its request to the proxy, the proxy decides what to do with it, and then it talks to the real destination. The response comes back the same way, in reverse.

There are two flavors, and the difference is whose side the proxy is on. A forward proxy sits in front of clients. When 5,000 employees in an office browse the web through one proxy, the websites they visit only see the proxy's IP address, not each employee's machine. A reverse proxy sits in front of servers. When you load a large website, you are almost always hitting a reverse proxy first, and it routes your request to one of many backend servers behind it.

The key idea is indirection. Because every request flows through one controlled point, the proxy can inspect, cache, block, rewrite, encrypt, or count traffic before passing it along. Neither the client nor the server has to know the other one exists directly.

At the network level, a proxy terminates the incoming connection and opens a new one to the target. For HTTP, a reverse proxy reads the request line and headers, looks at fields like Host and the URL path, and uses rules to pick a backend. Nginx, for example, matches the request against location blocks and forwards it to an upstream group, often round-robin across several servers.

Forward proxies often work through explicit client configuration. Your browser or operating system is told to send all traffic to proxy.example.com on port 3128, and it uses the HTTP CONNECT method to tunnel HTTPS traffic. The proxy can then allow or deny destinations by domain.

Reverse proxies add real work on the request path: they terminate TLS so backends do not each need certificates, they cache responses so identical requests never reach the origin, they compress responses with gzip or brotli, and they add headers like X-Forwarded-For so the backend still knows the original client IP. Because the proxy is the single front door, it is also the natural place to enforce rate limits and block bad requests.

Use a forward proxy when you need to control or anonymize outbound traffic: corporate filtering, content blocking, hiding client identity, or caching shared downloads for a whole office. Use a reverse proxy when you run servers and want a single, controllable entry point for TLS termination, load distribution, caching, and security filtering.

The cost is that a proxy is one more hop, so it adds a little latency, and if it goes down without a backup it takes everything with it. That is why production reverse proxies run in pairs or pools behind a health check or a load balancer.

People often confuse a reverse proxy with a load balancer. They overlap: a load balancer's main job is spreading traffic across servers, while a reverse proxy's broader job includes caching, TLS, header rewriting, and routing by URL. Many tools like Nginx and HAProxy do both, which is why the line is blurry.

Imagine an online store running on ten identical application servers. You put Nginx in front as a reverse proxy on port 443. A shopper's browser connects to the store, Nginx terminates the HTTPS connection, and then forwards the plain HTTP request to whichever app server is least busy.

If the request is for the homepage image or a product photo, Nginx serves it straight from its own cache and the app servers never see it. If it is a checkout request, Nginx adds X-Forwarded-For so the app knows the real customer IP, applies a rate limit so one bot cannot hammer checkout, and passes it through.

From the shopper's side there is one address and one certificate. Behind the proxy you can add, remove, or restart app servers at any time, and the shopper never notices. That single point of control is the entire reason proxies are everywhere in modern infrastructure.