Whose side it stands on
| Type | Represents | Typical use |
|---|---|---|
| Forward | Client | Exit via firewall, egress from intranet, cache |
| Reverse | Server | Load balance, TLS termination, hide backends |
Forward proxy
The client is configured to send all outbound requests to it first; the proxy then fetches the resource. The user knows a proxy is in use, often to reach restricted content or unify egress.
Reverse proxy
It sits in front of the server: one public address that dispatches to several backends. Users never see the backends. Nginx, API gateways and CDN edges are reverse proxies.
What it also does
- TLS termination: decrypt at the proxy so backends talk plaintext internally and save CPU;
- Load balance: spread traffic across instances;
- Security headers and rate limits: handled centrally at the edge.
Real-world cases: three strange problems caused by proxies
- No real client IP: behind a reverse proxy the server only sees the proxy address, breaking logs and rate limiting. Forward
X-Forwarded-Forand parse it only at a trusted proxy. - Redirecting to an internal address: the app builds redirects from its internal Host and sends users to
http://10.x.x.x. ForwardX-Forwarded-HostandX-Forwarded-Protoso it produces public URLs. - A forward proxy becoming an open proxy: an internal proxy without authentication or egress allowlists gets scanned and abused. Always restrict sources and destinations.
FAQ
Forward vs reverse proxy? A forward proxy acts for the client reaching outward; a reverse proxy acts for the server facing the world. Can X-Forwarded-For be trusted? No, it is spoofable; trust it only when the request truly came from a trusted proxy, and take the rightmost trusted value. Can a reverse proxy replace a load balancer? They are often combined: the proxy terminates TLS and routes, the balancer distributes and health-checks. Should rate limiting live in the proxy? The edge can absorb bulk abuse, but per-user business limits belong in the app or gateway.
Verifying proxy configuration
A proxy sits mid-path, so a bad configuration often looks like a problem elsewhere. These steps confirm it before and after release.
- Log headers per hop: record the key headers (source address, host, scheme, request ID) on both the proxy and the application. Comparing the two immediately shows whether the proxy failed to add them or the app failed to read them.
- Define trusted proxy ranges: the app should honour forwarding headers only from known proxy networks and ignore the same headers from anyone else, or address-based rate limiting and auditing can be spoofed.
- Watch redirects and assets: redirects, static asset links and links in emails all depend on the external host and scheme. Forwarding the client address but not the host or protocol sends users to internal addresses or http URLs.
- Keep timeouts consistent: the proxy timeout must exceed normal application time but stay under the caller's patience. Letting each layer grow is the classic cause of cascading timeouts, so budget timeouts per layer.
- Connection reuse and idle recycling: oversized or slow-recycling backend pools keep using stale connections after a restart, showing up as sporadic 502s. Shorten idle recycling and enable health checks.
Security boundary
A reverse proxy usually terminates TLS and applies authentication, so it is part of the security boundary: certificates, access logs and rate limits belong there. A forward proxy must authenticate users and allowlist destinations — never become an open relay.