Forward and reverse proxies

01Who does the intermediary represent?

Jo’s browser requests a supplier’s catalog from the company office. Follow who controls each intermediary:

1. The browser sends outbound traffic through a company service. That service applies the company’s destination rules and forwards permitted requests for employees. It acts for the clients, so it is a forward proxy.
2. The request reaches the supplier’s public entry service. This service receives requests for the supplier’s private application servers and forwards them inward. It acts for the servers, so it is a reverse proxy.
3. The catalog application reads its data and produces the response. Neither proxy needs to own the catalog records.

A proxy is an intermediary that receives and forwards traffic on another participant’s behalf. Its role depends on whom it represents, even though every proxy both receives and sends traffic.

Separate related responsibilities:

• Proxying forwards traffic on another participant’s behalf.
• Load balancing selects which application server receives traffic.
• One reverse proxy can do both jobs. A product’s name alone does not describe its role in this request.

Each added hop can also delay or fail a request. Show where it waits, which information it can inspect, and what information it is allowed to change.

02Trace encryption and identity through the hops

Jo uses HTTPS so the catalog request is encrypted while travelling over a connection. TLS, or Transport Layer Security, provides that connection protection. Locate its endpoints before saying which intermediary can read the content.

1. The company forward proxy can set up a tunnel and relay encrypted bytes between Jo and the supplier. In that mode it does not read the HTTP body. To read the body, the company proxy would have to end that encrypted connection under an inspection arrangement the client trusts, then open another connection toward the supplier. That is different from relaying an opaque tunnel.
2. The supplier’s reverse proxy may end the TLS connection. This is TLS termination: the proxy can now read HTTP and choose an application destination.
3. The proxy opens a separate connection to the application. Decide how that connection is encrypted and how the application verifies the proxy. Protection of the public connection does not automatically protect this new hop.
4. The application checks the verified account’s permission for the requested record. Knowing that Jo is signed in does not give Jo permission for another account’s invoice.

A header that claims a caller address or identity is just request text until its source is trusted. For example, a public caller can write a fake X-Forwarded-For header.

To use forwarded information safely:

1. Configure the trusted proxy to remove or overwrite untrusted caller-supplied values.
2. Configure the application to accept the resulting information only from that trusted proxy path. Prevent a direct-origin route from bypassing the rule.
3. Check permission for the particular resource after establishing identity. Forwarding a true account name does not grant access to every record.

The same reasoning applies when proxies forward language, scheme, or host information used to construct a response: say who supplies it and whether the application may trust it.

03Check caching, retries, and streaming

A proxy can change visible behavior even when the application code is correct. Test three common cases.

Private cached responses

1. Jo requests /profile and the application returns Jo’s details.
2. A shared proxy cache saves the response using only the URL as its key.
3. Another user requests the same URL and receives Jo’s saved response without reaching the application.

Prevent shared reuse of that private response, or isolate every permitted copy using verified identity and all other fields that change the result. Follow the HTTP caching rules. An application permission check cannot protect bytes that the proxy serves without contacting it.

A response lost after a purchase

1. The application saves a purchase.
2. Its connection to the proxy closes before the response arrives.
3. The proxy sees a disconnect, but does not know whether the purchase committed.
4. A blind repeat can create a second purchase. Follow the service’s retry contract: retain the same supported operation identifier and recover its saved outcome. Bound retries by the remaining time budget.

A delayed progress stream

• The application can produce one event per second while the proxy holds events until a larger chunk accumulates. Check buffering and flushing through the deployed path.
• Idle-timeout settings can close a quiet stream. Protocol upgrades and connection limits must also support the chosen mechanism.
• Replacement closes long-lived connections. Clients need a reconnect and progress-recovery policy.

Give a request a tracing identifier and carry it across proxy and application observations. This connects the same request’s waiting times and failures; the identifier does not grant permission or make repeated writes safe. Finally, test a proxy failure and a gradual rollout. A shared proxy policy mistake can affect every application behind it.