Files
Shaz 42b8971744
Build and deploy Docusaurus / build-and-deploy (push) Successful in 1m1s
Add network & containerisation
2026-03-10 20:31:37 +01:00

94 lines
3.8 KiB
Markdown
Raw Permalink Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# 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.