Forward and Reverse Proxies: Routing, Trust, and Use Cases

The word proxy describes an intermediary, not one specific network product. A forward proxy usually represents clients as they reach other services. A reverse proxy usually represents one or more services as clients reach them. Both can handle HTTP, but their users, trust boundaries, and routing decisions differ.

That distinction matters in production. A proxy can simplify egress policy or shield backend addresses, but a bad trust rule can expose spoofed client IPs, leak credentials, or turn a temporary slowdown into a queue of stuck requests. Proxying is a design choice with operational costs, not a security upgrade by itself.

Introduction

Proxy placement starts with the traffic path: which side initiates the connection, which hop can inspect it, and which component may assert client identity. Those choices shape routing, caching, and failure behavior.

This guide compares their roles and common deployment choices, then covers failure modes, observability, and security boundaries. It helps you decide where a proxy belongs and what to check when requests fail at that hop.

When to Use

Forward proxies

An organization may route outbound web traffic through a forward proxy to apply an explicit egress policy, require user or device authentication, log destinations, or reach the internet from a network that has no direct route. A developer can also configure a local proxy to inspect test traffic or work through an approved corporate gateway.

Illustrative curl example: this sends an HTTP request through an HTTP forward proxy. Replace the proxy and destination with approved endpoints.

curl --proxy http://proxy.example.net:8080 https://example.com/

For an HTTPS destination, curl typically asks the HTTP proxy to establish a CONNECT tunnel. After the proxy accepts, the client and origin negotiate TLS through the tunnel. The proxy can see connection metadata such as the destination host and traffic volume, but it cannot read the encrypted HTTP request unless TLS inspection is separately configured and trusted by the client.

Reverse proxies and gateways

Use a reverse proxy when the service needs one public entry point for several application instances, path or host based routing, TLS termination, response caching, request size limits, or a controlled place to apply rate limits. An API gateway adds API-specific functions such as authentication policy or request transformation; it still needs clear ownership of those policies and a reliable path to its upstream services.

A reverse proxy can also keep backend addresses off public DNS and restrict direct inbound access to the application tier. That reduces exposure only if network rules prevent clients from bypassing the proxy and the proxy itself is maintained, patched, and configured correctly. For a deeper look at distributing traffic, see Load Balancing: Traffic Control for Modern Infrastructure. For network boundaries and service connectivity, see Network Security: VPC, Firewall Rules, and Service Mesh mTLS.

When NOT to Use

Do not insert a proxy simply because a diagram looks cleaner with one. Each hop adds connection management, configuration, and another place where latency or failure can accumulate.

Avoid a forward proxy if the organization has no clear egress policy, support owner, or logging and retention rules. A proxy that everyone can bypass gives a false sense of control; one that blocks required dependencies without a usable exception process creates outages and workarounds.

Avoid a reverse proxy when the application already provides the required routing and TLS behavior and there is no operational need for another layer. Be especially cautious about TLS interception for general client traffic: it expands who can access plaintext, complicates certificate trust, and can break certificate pinning or mutual TLS. Do not terminate TLS merely to inspect a request unless the privacy, key custody, and compliance implications are understood.

Production Failure Scenarios

The proxy is reachable, but the request hangs

A successful TCP connection to the proxy proves only that the first hop accepted a connection. The proxy may still be unable to resolve the upstream name, establish TLS, or receive a response before its timeout. Compare client, proxy, and origin timestamps; identify which hop last logged progress; and check DNS, connection, TLS handshake, and response timeout metrics separately.

A retry storm amplifies an origin slowdown

If clients, a gateway, and a service mesh all retry the same failed request, one user action can become several backend attempts. Under load, retries fill proxy connection pools and extend queues. Set a retry budget, honor idempotency, cap attempts, and use timeouts that leave enough time for the whole request path.

A forwarded header is trusted from the wrong peer

An application may use X-Forwarded-For or Forwarded to record a client address or make access decisions. If it accepts those headers directly from any client, an attacker can supply a fake address. Trust only headers inserted or sanitized by known proxy hops, and block direct access to the origin when the deployment depends on proxy-provided identity.

TLS works at the edge but fails upstream

TLS termination at the reverse proxy creates one client-facing connection and a separate upstream connection. A missing backend certificate, wrong SNI, expired trust bundle, or incompatible protocol setting can fail only the second leg. Monitor both handshakes and test the proxy-to-origin path directly from the proxy’s network context.

A proxy loop forms

Misrouted upstreams can send a request back to the same proxy, or two proxies can route to each other. Symptoms include repeated redirects, rising hop counts, duplicated access logs, and requests that reach a hop or time limit. Check upstream hostnames, service discovery, Location rewriting, and loop-prevention rules. A proxy should have a clear route to the next hop, not a vague route back to “the public endpoint.”

Trade-Off Table

Observability Checklist

• Record a request or trace ID at the edge and propagate it to the chosen upstream without trusting a client-supplied value blindly.
• Separate client-to-proxy, proxy-to-upstream, TLS handshake, and total response latency. A single latency number hides where time was spent.
• Track upstream connect failures, DNS failures, TLS errors, timeouts, retries, open connections, queue depth, and healthy backend count.
• Log the selected route and upstream identity. Redact credentials, cookies, authorization headers, and sensitive query parameters.
• Compare response status at the proxy and origin. A proxy-generated 502 or 504 is different from an application response with the same code.
• For forward proxies, monitor denied destinations and authentication failures while limiting collection to the organization’s stated purpose and retention period.
• Alert on sudden changes in 4xx/5xx rates, tunnel failures, certificate expiry, and request volume per upstream.

For a focused incident, use a request that is safe to repeat and compare the route through the proxy with a direct upstream request from an authorized host. curl -v can expose CONNECT negotiation and TLS handshake details; avoid verbose output in shared logs if it could reveal credentials or private request data.

Security and Compliance Notes

Treat each proxy as a security boundary only to the extent its configuration enforces one. A reverse proxy does not protect an origin that remains directly reachable. A forward proxy does not control traffic from devices or workloads that have another egress path.

Forwarded client identity headers are assertions made by intermediaries. Strip untrusted inbound copies at the first trusted edge, then append or overwrite values according to a documented hop policy. The application should know exactly which peers are allowed to set those values. Do not use an arbitrary header as authentication.

TLS termination means the proxy holds or can access private keys and sees plaintext for that leg. Limit administrative access, rotate certificates, encrypt proxy-to-origin connections when required, and define where request bodies and logs may be stored. For CONNECT tunnels, restrict destination ports and destinations according to policy; a tunnel is not automatically harmless just because the proxy cannot read its contents.

Logs can contain personal data, URLs with secrets, or internal hostnames. Decide what is collected, who can query it, and when it is deleted. Keep access controls and retention consistent with applicable privacy and compliance requirements.

Common Pitfalls / Anti-Patterns

• Treating X-Forwarded-For as inherently trustworthy. Trust is based on the immediate peer and a known proxy chain, not the header’s name.
• Assuming every HTTP proxy terminates TLS. CONNECT often passes encrypted bytes after tunnel setup; interception is a separate, consequential configuration.
• Using one timeout everywhere. DNS, connect, TLS, idle, and total request timeouts describe different waits. Set them with the application’s latency budget in mind.
• Retrying every method and status. Repeating a non-idempotent operation can create duplicate writes or charges.
• Leaving origins publicly reachable. Clients can bypass routing, authentication, or limits that exist only at the reverse proxy.
• Caching personalized responses by URL alone. Cache keys and directives must account for authorization, cookies, and Vary; otherwise one user can receive another user’s content.
• Forwarding hop-by-hop headers as if they were end-to-end metadata. HTTP intermediaries need to process connection-specific headers according to the protocol and remove or regenerate them as appropriate.
• Building a proxy chain with no owner. Every hop needs an operator, a configuration source, and a way to tell which hop failed.

HTTP semantics for intermediaries, connection management, and the CONNECT method are defined in RFC 9110. The protocol details are useful when a proxy behaves differently from what a product diagram suggests.

Quick Recap Checklist

• Identify whether the proxy represents clients or origin services.
• Draw the actual hops, including TLS termination and the next upstream.
• Decide which forwarded headers are trusted and which peers may set them.
• Set connect, handshake, idle, and total timeouts deliberately.
• Bound retries and confirm they are safe for the request method.
• Prevent bypass to origins when edge policy is required.
• Check cache keys, privacy exposure, log retention, and certificate ownership.
• Test proxy failure, upstream failure, and recovery behavior before relying on it.

Interview Questions

Further Reading

• RFC 9110: HTTP Semantics
• MDN: Proxy servers and tunneling
• MDN: Forwarded header
• Load balancing concepts
• Network security and service boundaries

Conclusion

Forward and reverse proxies both sit between network peers, but they serve different sides of a request. Their real behavior depends on whether they relay or terminate connections, which headers they trust, how they route and cache, and what happens when an upstream slows down. Map the hops, define the trust boundary, and instrument each leg before making a proxy responsible for production traffic.