Forward and reverse proxies

A forward proxy sits near the client — corporate proxies, VPN egress, developer tools. Clients configure it explicitly. A reverse proxy sits in front of servers — Nginx, Envoy, cloud load balancers. Clients think they talk to one origin.

					Forward:  Client → Proxy → Internet → Origin
Reverse:  Client → Reverse proxy → App servers
				

Reverse proxies terminate TLS, route by host/path, add headers (`X-Forwarded-For`, `X-Request-Id`), buffer slow clients, and shield app processes. Trust only sanitized forwarding headers from known hops.

On interviews: explain why Node apps bind to private ports behind a reverse proxy; how to recover client IP safely; difference from API gateways (more policy at gateway layer).

Common pitfalls: trusting spoofed `X-Forwarded-For` from the public internet; double compression; losing WebSocket upgrade headers.

The trade-off is balancing simplicity, performance, safety, and operability — name which axis you optimized and what cost you accepted.

Checklist:

• Place TLS and public exposure at the reverse proxy.
• Validate forwarding headers at the trust boundary.
• Preserve hop-by-hop headers needed for upgrades.
• Document which proxy owns timeouts and buffering.