openskills.info
Course Preview

Reverse Proxy Fundamentals

A reverse proxy is a server that accepts requests on behalf of one or more backend servers, chooses where each request goes, and returns the backend response. It gives clients one public endpoint while keeping backend addresses and traffic rules behind that boundary.

itWeb servers, proxies, and traffic management

Don't Panic — Reverse Proxy Fundamentals

A reverse proxy is the doorman for a service that has decided its backends should not answer the public door directly. A client talks to the proxy as if it were the origin server. The proxy then decides where the request goes and returns the answer. This sounds like a small administrative detail, which is how it gets enough responsibility to become interesting.

Before this boundary exists, a public name points at one server and that server must do everything visible to the client. With the proxy in front, the public name can stay put while backend addresses, ports, and server counts move around behind it. The proxy can also route by host or path, terminate TLS on the client-facing connection, select a healthy backend, cache eligible responses, and record traffic. It is not magic. It is a place to put decisions.

The important shape is two connections, not one. There is a client-facing connection from the client to the proxy, then a backend-facing connection from the proxy to the selected server. TLS termination therefore ends one protected connection; it says nothing by itself about the next one. Likewise, the backend usually sees the proxy as its immediate peer, not the original client. This is where a surprising amount of confident configuration turns into a very polite misunderstanding.

A route is the proxy's answer to “where does this request belong?” Layer four routing uses connection information such as address and port. Layer seven routing can use HTTP data such as host and path. Use the smallest layer that can make the decision. Specific routes need predictable precedence, and an unknown host should fail safely. Otherwise a request can arrive at a real application merely because the configuration ran out of ideas.

The second idea is that proxy behavior changes HTTP behavior unless you constrain it. A rewrite, timeout, retry, cache key, or forwarded header is policy. A backend pool can distribute requests and health checks can remove a failed target, but neither adds capacity or makes one proxy redundant. A retry can also repeat work that a backend already processed, which is a bad moment for optimism.

Start with the cheatsheet when you need the moving parts and the failure signals in one place. The slides make the request path and routing choices easier to compare. The practice reference then gives you a local listener and backend to inspect, while the exercise makes one listener route to two backends. The reference tab is where the precise protocol and product behavior waits, patiently, with considerably less charm.

Where this skill leads

Relevant careers

See how this topic contributes to broader role-level skill maps.

Sources