DesignFlix 3: Whose Side Does a Proxy Serve?

A proxy sits between a client and a server. That sentence describes both a forward proxy and a reverse proxy, so it doesn't explain the difference yet.

The useful question is whose side the intermediary represents. A company can control outbound browsing through a forward proxy. A website can receive inbound requests through a reverse proxy. Both forward traffic, but their configuration and trust belong to different sides.

Let's follow one browsing request and one website request to see the distinction.

A forward proxy represents the client side

Suppose an office configures browsers to send external requests through an outbound proxy. The browser asks the proxy to reach a destination, and the proxy makes or relays the connection under its policy.

The simplified path is:

Office browser -> Forward proxy -> Public website

The organisation can use that point to restrict permitted destinations, record appropriate access information or cache eligible responses. These capabilities depend on the proxy and configuration; a middle server doesn't automatically provide all of them.

For a direct outgoing connection made by the proxy, the destination sees its network address as the connection source. That changes the visible network route, not the logged-in user's account. Cookies and account activity can still identify the person to the website.

HTTPS changes what the intermediary can read

For conventional HTTPS through an HTTP proxy, the client can request a tunnel using CONNECT, then establish TLS through it to the destination. The HTTP standard defines that tunnelling method.

A tunnelling proxy can relay encrypted bytes without seeing the decrypted page content. It still has connection information, and the destination named in the tunnel request is useful metadata.

Some managed environments configure TLS inspection under an additional trust arrangement. That is a different setup, not something every forwarding proxy obtains automatically. Ask where TLS terminates before saying a proxy can read or filter the full request.

A reverse proxy represents the server side

Now someone opens a website. Its public endpoint reaches a reverse proxy, which selects and forwards to the appropriate backend.

Visitor browser -> Reverse proxy -> Website application

The visitor doesn't need the application's internal address. The website operator controls how the proxy routes /articles, API calls or other paths. Backends can change while the public endpoint stays stable.

A capable reverse proxy may terminate TLS, balance requests, cache eligible responses or apply configured limits. Those are possible jobs, not the definition itself. NGINX's reverse-proxy guide shows this server-side arrangement.

For a TLS-terminating proxy, the browser's secure connection ends at that component. The connection from proxy to backend has its own security configuration. Don't assume one padlock describes both hops.

Backend ko main sambhal lunga.

The same request can meet both kinds

An office browser may send its request through the company's forward proxy. The public website may then receive it through its reverse proxy.

There is no contradiction. One intermediary represents the outbound client environment, while the other represents the destination service. The combined path simply has both responsibilities.

Who configured this intermediary, and whose traffic policy is it enforcing?

That usually explains the label more clearly than asking whether it is physically "in front of" something. Both are in front of another component from someone's perspective.

Hiding an address isn't complete protection

A reverse proxy can keep internal routing details out of the public interface. It doesn't guarantee that backends are unreachable by another path. Configure the network and backend access policy to match the intended entry point.

Similarly, a forward proxy isn't an anonymity promise. Destination logins can identify the user, and the proxy operator has its own visibility. Decide what threat or operational requirement the intermediary is meant to address.

Large traffic attacks can also exhaust capacity before a small reverse proxy gets a chance to reject them. Wider network protection and provider capacity may be required. Proxying alone isn't a universal DDoS defence.

Forwarded information needs a trust rule

A reverse proxy may send the original client address in a header so the application can use it for logs or limits. The application should accept that information only through a known trusted proxy path that removes or overwrites untrusted client values.

Otherwise, a public caller may supply a fake address and confuse the very controls that rely on it. Connection source and forwarded client identity are related information, but they aren't the same observation.

Trace the path before choosing the label

For the office browser, inspect the configured outbound route and TLS boundary. For the website, inspect the public entry point, backend route and trusted metadata.

Forward and reverse proxies become easy to distinguish once we know whose side they serve. That distinction also makes debugging more useful: we can ask which policy blocked the destination, where encryption ended, and which component supplied the address the application logged.