A reverse proxy sits in front of backend services and forwards client requests to them, providing a single public entry point for routing, caching, termination, and security.
A reverse proxy receives requests from clients and routes them to backend servers based on path, host, headers, or weight. It can terminate TLS, compress responses, cache static content, enforce authentication, and hide internal network topology from clients.
That single entry point simplifies clients and centralizes cross-cutting concerns. Instead of every client knowing every backend address and protocol, they talk to one endpoint. The proxy handles protocol differences, security boundaries, and traffic shaping. The risk is making the proxy a critical path bottleneck or a single point of failure without proper scaling and failover.
Think of it like this. Think of a hotel front desk. Guests do not enter individual rooms directly; they check in at the desk, which routes them, verifies identity, and handles requests on their behalf.
Clients send requests to a public hostname or IP. The proxy inspects the request, selects a backend using rules, forwards the request, and returns the backend response. Caching, compression, authentication, rate limiting, and request rewriting are applied at this boundary. Load balancing distributes requests across healthy backends.
"Reverse proxy and load balancer are the same." A load balancer distributes traffic; a reverse proxy adds request inspection, caching, and protocol handling. "Any proxy solves security." Proxies reduce exposure but still require backend authorization, input validation, and least privilege. "One proxy handles everything." Specialized edge, API, and internal proxies often coexist.
Centralizes routing, security, and protocol handling, but adds hop latency and a critical path component. Strong default for public APIs and SaaS; internal mesh proxies add complexity without benefit in small environments.