DEVBOOK

Forward and Reverse Proxies

2 min read

Edit this pageReport / suggest

A proxy terminates one connection and opens another on behalf of a represented party. A forward proxy represents egress clients; a reverse proxy represents origins for inbound traffic.

For concrete implementation patterns and configuration tradeoffs, see Nginx.

Trust and Scope

Choose proxy type by ownership and failure boundary:

  • Forward proxy: policy-controlled client path to external services.
  • Reverse proxy: public entry point for service traffic, plus routing, TLS edge, and buffering.

Neither is automatically secure. Identity and trust are defined by configuration controls: authentication, rewritten headers, certificate handling, and bypass policy.

If you use an enterprise forward proxy with interception, TLS is terminated at the proxy and headers are policy-bound. If you use a non-intercepting tunnel, encryption remains end-to-end to the upstream endpoint.

Example

  • Forward proxy: Browser -> enterprise forward proxy CONNECT api.example.com:443 -> target normally makes the target observe the proxy’s network address. The proxy still sees the client, and authentication or forwarding metadata can expose client identity, so it remains a trusted observer that needs strict allowlists and tunnel policy.
  • Reverse proxy: Internet client -> reverse proxy (TLS terminate) -> app service centralizes ingress rules. If the reverse proxy drops or rewrites X-Forwarded-For incorrectly, downstream systems can record the proxy IP instead of the real client.

Shared Failure Pattern

Proxy centralization concentrates outage risk. Redundant instances reduce single-path blast radius, and 502/504 class failures usually indicate upstream/proxy boundary issues before application logic.

References

Graph View

Backlinks