a reverse proxy

Think of a large company's front receptionist. Visitors don't wander the building looking for the right person; they all arrive at one desk, and the receptionist routes each to the correct department, turns away unwanted callers, and presents a single, polished face for the whole organization. A reverse proxy is that receptionist for a website: a server placed in front of one or more origin servers, which receives all incoming client requests and forwards them to the appropriate backend, then returns the backend's response to the client.

From the client's point of view, the reverse proxy is the website — clients connect to it and never see the real servers behind it. That single front door is a powerful place to add capabilities without changing the backends: load balancing (spreading requests across many servers), caching (answering repeat requests itself so backends stay idle), TLS termination (handling HTTPS encryption in one place), compression, request filtering, and hiding the number and addresses of the real machines. When a request arrives, the reverse proxy may answer from its own cache, or pick a healthy backend and relay the request, attaching headers that tell the backend who the real client was.

Why it matters: the reverse proxy is the workhorse behind scalable web architecture, and it is the conceptual heart of a CDN edge server — both stand in front of an origin and serve clients on its behalf. It contrasts cleanly with a forward proxy: a forward proxy acts for the clients and faces the servers; a reverse proxy acts for the servers and faces the clients. A caveat worth stating: because the reverse proxy terminates the client connection, it sees request and response content in the clear (after decrypting TLS), so it is a trusted, security-sensitive component — and a single point that must itself be made highly available.