# Reverse Proxy – Basics

What a reverse proxy does and why it sits in front of web services.

For generic networking concepts, see:

- [Network / Basics](./Basics.md)
- [Security / Certificates](../Security/Certificates.md)

For my concrete Caddy setup on the home server, see:

- [Home-Server / Caddy implementation](../Home-Server/Implementations/DNS/Caddy.md)

---

## Scope

- What a reverse proxy is and how it differs from a forward proxy.
- Routing by hostname (virtual hosts).
- TLS termination.
- Brief comparison of common tools.

---

## 1. What Is a Reverse Proxy?

A **reverse proxy** is a server that sits in front of one or more backend services. Clients connect to the proxy, and the proxy forwards the request to the appropriate backend.

```
Client → Reverse Proxy → Backend service A
                       → Backend service B
                       → Backend service C
```

From the client's perspective there is only one entry point. The proxy hides the internal layout of services.

A **forward proxy** is the opposite: it sits in front of clients and forwards their requests to external servers (used to filter or log outbound internet traffic). What is described here is always the reverse variant.

---

## 2. Why Use One?

- **Single entry point** — all traffic enters on ports 80 and 443. Backends do not need to be exposed directly.
- **Hostname-based routing** — one IP can serve many services, each with its own domain name.
- **TLS termination** — HTTPS is handled once at the proxy; backends communicate over plain HTTP internally.
- **Centralised logging** — request logs are in one place.
- **Header manipulation** — add security headers, forward the real client IP, etc.

---

## 3. Hostname-Based Routing (Virtual Hosts)

HTTP/1.1 requires clients to send the target hostname in the `Host` header. HTTPS clients send it via **SNI** (Server Name Indication) during the TLS handshake.

The reverse proxy reads this and routes to the matching backend:

| Incoming host       | Forwards to           |
|---------------------|-----------------------|
| `jellyfin.lan`      | `localhost:8096`      |
| `vaultwarden.lan`   | `localhost:8080`      |
| `home.lan`          | `localhost:3000`      |

This is how a single machine with one IP can serve many services on the same port 443.

---

## 4. TLS Termination

**TLS termination** means the reverse proxy handles HTTPS encryption and decryption. Each client sees a valid HTTPS connection; the proxy communicates with backends over plain HTTP on the internal network.

This simplifies backends — they do not need to manage certificates themselves.

Two certificate scenarios:

- **Public domain + Let's Encrypt** — certificates are fetched automatically via the ACME protocol (HTTP-01 or DNS-01 challenge). Trusted by all browsers.
- **Internal network** — a private CA issues certificates. Browsers need to import and trust this CA's root certificate. Tools like Caddy automate this with `tls internal`.

For more on certificates and trust chains, see:

- [Security / Certificates](../Security/Certificates.md)

---

## 5. Common Tools

| Tool        | Notable characteristics                                                                             |
|-------------|-----------------------------------------------------------------------------------------------------|
| **Caddy**   | Automatic HTTPS by default (Let's Encrypt + internal CA), simple `Caddyfile` syntax, minimal setup |
| **Nginx**   | Very widely used, highly configurable, manual certificate management (or paired with Certbot)       |
| **Traefik** | Docker-native, auto-discovers services via container labels, suited for dynamic environments         |
| **HAProxy** | Focus on high-performance load balancing, lower-level than the others                               |

For a personal home server, Caddy or Traefik are the most convenient.