A proxy is a helper server that sits in the middle and forwards traffic.

The confusing part is that two very different systems can both be called a "proxy." The easiest way to tell them apart is to ask one question:

Whose side is the proxy on?

A forward proxy is on the client's side. It helps clients reach other servers.

A reverse proxy is on the server's side. It helps servers receive traffic from clients.

For example, a company might send employee web traffic through a forward proxy so it can block unsafe sites, keep audit logs, or control which services employees can access.

A web service might put a reverse proxy in front of its backend servers so public users only talk to one safe entry point. The reverse proxy can then handle HTTPS, route requests, spread traffic across servers, and block suspicious requests.

The simulation below shows the same request flowing through each type.

This chapter explains the difference step by step, using the mental model engineers actually use in production.

A forward proxy sits between clients and the outside servers they want to reach.

The outside server sees the proxy, not the original client, as the direct caller.

That lets the proxy hide the client's IP address, apply company rules, log requests, cache common responses, or block unsafe traffic.

Request flow:

For plain HTTP, the client may know it is using a proxy and send requests to it directly.

For HTTPS, the proxy often uses the CONNECT method. Think of CONNECT as asking the proxy to open a tunnel to the target site. The encrypted HTTPS traffic then flows through that tunnel.

Some companies also do TLS inspection. In that setup, the proxy decrypts HTTPS traffic, checks it, and then creates a new encrypted connection to the destination. This only works when the client device trusts a company-managed certificate authority.

That gives the proxy a lot of visibility, so it must be treated as a sensitive trust point.

Why Teams Use Forward Proxies

Forward proxies are common when an organization wants control over traffic leaving its network.

Do not confuse IP masking with true anonymity.

A proxy may hide your IP from the destination, but the proxy operator can still log who you are, where you connect, when you connect, and sometimes what you send. The destination site may also recognize you through cookies, logins, browser fingerprints, or application tokens.

Proxy vs VPN

A VPN and a forward proxy both send traffic through another system, but they work at different levels.

A reverse proxy sits in front of backend servers.

Clients connect to the reverse proxy. The reverse proxy then chooses where to send each request.

To the client, the service looks like one stable endpoint. Behind the scenes, backend servers can be added, removed, replaced, restarted, deployed, or kept private.

Request flow:

Reverse proxies are common because they create a controlled front door between public clients and private infrastructure.

What Reverse Proxies Provide

Examples include NGINX, HAProxy, Envoy, Apache httpd, Traefik, Caddy, Cloudflare, Fastly, AWS Application Load Balancer, Google Cloud Load Balancing, Azure Application Gateway, and Kubernetes ingress controllers.

The naming is confusing because both are "in the middle." The side they represent is what makes them different.

Proxies can work at different layers of the network stack. The two common ones are Layer 4 and Layer 7.

Layer 4 Proxy

A Layer 4 proxy works with TCP or UDP connections.

It can see network-level details like IP addresses, ports, and whether a connection is open or closed. It usually does not understand HTTP paths, headers, cookies, or request bodies.

Layer 4 is useful when the traffic is not HTTP, when you want simple and fast forwarding, or when encrypted traffic should pass all the way to the backend without being decrypted by the proxy.

Layer 7 Proxy

A Layer 7 proxy understands the application protocol, usually HTTP.

It can make decisions using hostnames, URL paths, HTTP methods, headers, cookies, gRPC methods, or carefully validated JWT claims.

Layer 7 gives you more control, but it also creates more ways to make mistakes. Once a proxy reads, changes, retries, or buffers requests, it is no longer just a pipe. It is part of how the application behaves.

Reverse proxies often handle HTTPS for the service.

The client creates an HTTPS connection to the proxy. The proxy then forwards the request to the backend either over plain HTTP or over a new HTTPS connection.

Common patterns:

This is an important security boundary. If a reverse proxy decrypts HTTPS, it must be trusted infrastructure. It can see headers, cookies, authorization tokens, request bodies, and responses.

The real question is simple: where is decrypted traffic allowed to exist?

With termination or re-encryption, traffic is briefly decrypted inside the proxy. That lets the proxy route by path, apply WAF rules, and add headers. The risk is that a compromised proxy can read the traffic.

With pass-through, the proxy forwards encrypted bytes without the key. It never sees the decrypted request.

In pass-through mode, the backend handles HTTPS and holds the certificate. The cost is that the proxy cannot inspect HTTP paths, headers, responses, or bodies, so many Layer 7 features are unavailable.

In short: terminate or re-encrypt when you need HTTP-aware features and trust the proxy. Use pass-through when keeping traffic encrypted all the way to the backend matters more.

For forward proxies, TLS inspection is even more sensitive because it affects user traffic. It can be appropriate in some company environments, but it should be explicit, documented, and controlled carefully.

When a reverse proxy forwards a request, the backend often sees the proxy's IP address as the direct caller.

If the backend needs to know the original client IP, original host, or whether the client used HTTPS, the proxy has to pass that information in headers.

Common headers:

Only trust these headers when they come from proxies you control. Public clients can fake headers like X-Forwarded-For.

A good edge proxy removes untrusted forwarding headers from incoming requests and writes clean ones before traffic reaches the application.

Many production bugs come from getting this wrong. Applications generate http:// redirects behind an HTTPS proxy. Rate limiters throttle the proxy IP instead of the real client IP. Audit logs record only load balancer addresses. Security checks trust fake client IP headers. Absolute URLs break because Host was not preserved.

Both forward and reverse proxies can cache responses, but they do it for different reasons.

Forward proxy caching saves bandwidth for a client network.

Reverse proxy caching reduces load on backend services and makes responses faster for users.

Caching has to follow HTTP caching rules. Important signals include Cache-Control, ETag, Vary, Authorization, cookies, query parameters, and content encoding.

The dangerous mistake is caching private or personalized data and then serving it to the wrong user. A reverse proxy cache should be careful with logged-in or user-specific responses unless the application clearly marks them safe to cache.

These terms overlap in real products, so do not worry if one tool seems to fit several labels.

A single system can play several roles. Envoy can be a reverse proxy, a load balancer, part of an API gateway, and a service mesh sidecar. Cloudflare can be a CDN, WAF, reverse proxy, and DDoS protection layer.

Labels matter less than behavior. Ask:

Here is a small NGINX reverse proxy for an HTTP backend.

Install and Reload

Start by installing NGINX, checking that the config is valid, and reloading the service.

Basic Reverse Proxy

This server block sends every request to one backend and sets headers that help the backend understand the original client request.

Load Balancing Across Backends

Adding an upstream block lets one proxy spread traffic across several backends. The failure settings help NGINX stop sending traffic to a server that is repeatedly failing.

NGINX uses round robin by default, which means it cycles through the backend servers. least_conn is useful when some requests take longer than others because it sends new requests to the server with the fewest active connections.

Sticky routing is possible, but use it carefully. It can hide the fact that the backend depends on local server state.

This example is intentionally small. Production configs also need HTTPS, access logs, request size limits, buffering choices, health checks or failure policy, compression, security headers, and timeouts that match the application.

Proxies make systems more flexible, but they also sit on the path every request must take.

Common failure modes:

For AI systems, pay special attention to long-running and streaming requests. Token streams, file uploads, batch jobs, and model inference calls need clear timeout, buffering, and cancellation behavior. A proxy tuned for short web requests can break these workflows under load.

Forward proxies and reverse proxies both sit in the middle, but they represent different sides.

A forward proxy represents clients. It controls traffic leaving a client network and is useful for filtering, privacy, logging, compliance, and controlled access.

A reverse proxy represents services. It controls traffic entering a system and is useful for HTTPS handling, routing, load balancing, caching, security filtering, rate limiting, monitoring, and logs.

Both are trust points. Be careful with forwarded headers, TLS inspection, caching, retries, and logs.

The best way to reason about a proxy is not just "it forwards requests." Ask what it can see, what it changes, what it caches, what it retries, what it logs, and what happens when it fails.