3.8 KiB
Reverse Proxy – Basics
What a reverse proxy does and why it sits in front of web services.
For generic networking concepts, see:
For my concrete Caddy setup on the home server, see:
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:
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.