Homelab from Zero #7: What a reverse proxy is and why you want one

6/24/2026/4 minutes to read/Tags: homelab-from-zero, homelab, networking

This is part 7 of Homelab from Zero. In part 6 you set up automated backups with Restic. Today there’s no new software to install, just one concept that unlocks everything in the next few parts: the reverse proxy.

The problem it solves

Right now your services each sit on their own port:

That works, but it’s friction. You have to remember port numbers. The browser shows “Not secure” because there’s no HTTPS. Adding a new service means picking another free port and hoping you don’t forget which one. The more services you run, the messier this gets.

A reverse proxy fixes all of it in one place.

What a reverse proxy actually does

Imagine a hotel front desk. Guests don’t wander the building looking for conference rooms; they ask the desk, and the desk directs them to the right place.

A reverse proxy is that desk. It sits at a single address, takes every incoming request, reads the hostname (e.g. heimdall.home or pihole.home), and forwards the request to the right service on the right port. The service responds, the proxy hands that response back to the browser. The browser only ever talks to the proxy.

Browser → asks for heimdall.home
              ↓
         Reverse proxy (port 80/443)
              ↓
         Heimdall on :8080

From the browser’s point of view, every service lives at a clean hostname with no port number. From each service’s point of view, nothing changed: it still just listens on its port and answers requests.

What you gain

Clean URLs. http://heimdall.home instead of http://192.168.1.73:8080. No port numbers to memorise.

HTTPS everywhere. The proxy handles TLS for every service in one place. The services themselves don’t need to know anything about certificates. In part 8 we’ll use Caddy to issue internal certs automatically, so every .home address shows a green padlock.

One place to manage access. Want to password-protect a service, redirect an old URL, or add a header to every response? You do it once in the proxy config, not in each service individually.

Easier to add services. New container? Point a new hostname at its port in the proxy config. No firewall rules to juggle, no ports to expose publicly.

How it fits the network

The proxy needs two things:

1. It listens on ports 80 and 443, the standard HTTP and HTTPS ports. Only one thing on the server can own port 80 at a time, so the proxy takes it and all services get out of the port-juggling business.

2. DNS points your hostnames at the proxy. When your laptop looks up heimdall.home, the answer should be the proxy’s IP. Pi-hole’s custom DNS records are perfect for this; you’re already running it.

The result: traffic flows browser → proxy → service and the whole path is invisible to you as a user. You just type a hostname.

What’s coming

In part 8 we install Caddy as the reverse proxy and wire up real HTTPS for every service in the lab, no browser warnings, no manual certificate handling. The groundwork you’ve built across the series (Docker, Pi-hole for DNS, a running set of services) makes that a straightforward afternoon’s work.