CONCEPT SHEET · Concepts

Proxies: Forward vs Reverse

One-liner: A forward proxy acts for clients going out; a reverse proxy acts for servers receiving traffic. Same box, opposite direction.

ArticleConcepts© Arthur Bernier Jr526 words1 code block

Say this#

How it works#

TEXT
Forward:  [client] -> [forward proxy] -> internet -> [server]     server sees proxy IPReverse:  [client] -> internet -> [reverse proxy] -> [servers]    client sees proxy IP

Reverse proxy request path:

  1. Accept TCP, terminate TLS (cert from Let's Encrypt/ACM).
  2. Parse HTTP, apply rules: redirect, rewrite, rate limit, auth subrequest, WAF.
  3. Add X-Forwarded-For, X-Forwarded-Proto, request ID.
  4. Pick upstream (load balance), forward with keep-alive connection pool.
  5. Buffer/compress response (gzip/brotli), cache if cacheable, return.

Forward proxy uses: enforce egress allow-lists, cache package downloads, hide internal IPs, inspect outbound traffic, bypass geo-blocks.

Trade-offs#

ChoiceProCon
Reverse proxy in front of appsTLS offload, central routing, caching, hides topologyExtra hop (~1 ms), another thing to run HA
TLS termination at proxyCert management in one place, inspectable trafficPlaintext inside the network unless re-encrypted (mTLS mesh)
SSL passthroughEnd-to-end encryptionNo L7 features at the proxy
Forward egress proxySecurity, auditing, cachingBottleneck, latency, config burden on clients
Sidecar per serviceUniform retries/mTLS/telemetryResource overhead per pod, added latency

Numbers#

  • Nginx/HAProxy add roughly sub-millisecond to ~1 ms per hop; handle tens of thousands of req/s per core order of magnitude.
  • TLS handshake: 1 RTT (TLS 1.3), 2 RTT (TLS 1.2); terminating near the user saves tens of ms.
  • Envoy sidecar overhead: ~0.5-3 ms p99 and tens of MB memory per pod, order of magnitude.

In the interview#

See also

Microservices vs MonolithObservabilityRate LimitingScaling: Horizontal vs Vertical