Wenn dein Homelab wächst, sammelst du Portnummern wie andere Leute Briefmarken: Uptime Kuma läuft auf 3001, Immich auf 2283, Vaultwarden irgendwo dazwischen. Im Browser tippst du dann Sachen wie 192.168.1.20:3001, weil du die Nummern inzwischen auswendig kennst. Kannst du so machen. Musst du aber nicht: Genau für dieses Problem gibt es den Reverse Proxy. Und der ist deutlich einfacher zu verstehen, als sein Name klingt.

Kurz gesagt: Ein Reverse Proxy ist die eine Eingangstür für alle deine Dienste. Er nimmt jede Anfrage auf Port 80/443 entgegen und reicht sie anhand des Namens an den richtigen Dienst weiter: merkbare Adressen statt Port-Zoo, HTTPS an einer einzigen Stelle. Lesezeit rund 7 Minuten, der Mini-Praxisteil danach nochmal etwa 10.
Schaubild: Der Weg einer Anfrage durch den Reverse Proxy — Browser fragt per Name, der Reverse Proxy nimmt auf Port 80/443 an und verteilt, der Dienst antwortet
Der ganze Trick auf einen Blick: ein Name rein, der richtige Dienst raus.

Das Problem: ein Server, viele Türen

Jeder Dienst auf deinem Server lauscht auf einem eigenen Port. Das muss so sein, zwei Programme können sich nicht denselben Port teilen. Was passiert, wenn sie es trotzdem versuchen, haben wir im Beitrag „Port belegt?" auseinandergenommen.

Port? Die Zimmernummer hinter der Hausadresse: Die IP-Adresse bringt eine Anfrage zum richtigen Server, der Port zum richtigen Programm darauf. 192.168.1.20:3001 heißt also: Haus 192.168.1.20, Zimmer 3001.

Solange du zwei Dienste betreibst, ist das nur unschön. Ab vier oder fünf wird es lästig. Niemand in deiner Familie merkt sich 192.168.1.20:2283, um Fotos anzuschauen. Und wenn du irgendwann Verschlüsselung willst, müsstest du sie für jeden Dienst einzeln einrichten. Es gibt einen eleganteren Weg.

Der Türsteher: So arbeitet ein Reverse Proxy

Ein Reverse Proxy ist ein Dienst, der sich vor alle anderen stellt. Er allein nimmt Anfragen aus dem Netz entgegen, und zwar auf den Standard-Ports 80 (HTTP) und 443 (HTTPS), also genau denen, die dein Browser von selbst benutzt, wenn du keine Nummer angibst. Dann schaut er in seine Regeln: Welcher Name wurde angefragt? Und leitet die Anfrage intern an den passenden Dienst weiter. Die Antwort holt er ab und reicht sie an den Browser zurück, so beschreibt es auch die NGINX-Doku.

Browser→ fotos.heim.lan →Reverse Proxy→ Port 2283 →Immich

Der Türsteher-Vergleich passt ziemlich gut: Vor einem Club mit fünf Räumen steht ein Mensch an der Tür, der jeden Gast fragt, wohin er will, und ihn dann in den richtigen Raum schickt. Kein Gast muss wissen, welcher Raum hinter welcher Tür liegt. Er muss nur den Namen kennen. Genauso rufst du künftig fotos.heim.lan auf statt einer IP mit Portnummer. Dein Browser redet dabei ausschließlich mit dem Proxy, nie direkt mit dem Dienst dahinter.

Wichtig zum Verständnis: Der Reverse Proxy ersetzt deine Dienste nicht und er hostet sie auch nicht. Er ist reine Vermittlung. Immich läuft weiter auf Port 2283, nur klingelt da jetzt niemand mehr direkt.

Warum eigentlich „reverse"?

Ein normaler Proxy (Forward Proxy) arbeitet für die Clients: Er sitzt zum Beispiel im Firmennetz, schickt deine Anfragen stellvertretend ins Internet und verbirgt dabei, wer genau angefragt hat. Wie jemand, der für dich einkaufen geht: Der Laden bekommt dich nie zu Gesicht.

Der Reverse Proxy macht dasselbe in die andere Richtung, er arbeitet für die Server: Er nimmt Anfragen stellvertretend für deine Dienste an und verbirgt, was hinter ihm läuft. Eher wie der Empfangstresen einer Firma: Du trägst dein Anliegen vor, und welcher Sachbearbeiter es am Ende bearbeitet, siehst du nie. Daher der Name — die Rollen sind vertauscht.

Was bringt dir das konkret?

  • Adressen, die man sich merken kann. uptime.heim.lan statt 192.168.1.20:3001. Auch für den Rest der Familie.
  • HTTPS an einer Stelle. Der Proxy übernimmt die komplette Verschlüsselung für alle Dienste gleichzeitig — statt zehnmal Zertifikats-Gefummel einmal.
  • Eine Tür statt zehn. Wenn du später mal etwas ins Internet freigibst, musst du nur einen einzigen Punkt absichern und im Blick behalten. Zugriffsregeln, Logs, alles an einem Ort.
  • Dazu kommen die Profi-Features, für die das Konzept ursprünglich gebaut wurde: Lastverteilung auf mehrere Server, Caching, Kompression. Brauchst du im Heimnetz selten, aber es ist derselbe Mechanismus, mit dem große Websites Millionen Anfragen verteilen. Du holst dir also Rechenzentrums-Technik ins Wohnzimmer, zum Nulltarif.
TLS-Terminierung? So heißt der HTTPS-Trick offiziell: Der Reverse Proxy spricht verschlüsselt mit dem Browser und intern normales HTTP mit deinen Diensten. Zertifikate brauchst du damit nur noch an einer einzigen Stelle: beim Proxy.

Welcher Reverse Proxy darf's sein?

Fürs Homelab haben sich vier Kandidaten etabliert, alle kostenlos und Open Source:

  • Nginx — der Klassiker. Läuft auf halbem Internet, zu jeder Frage existiert eine Antwort. Konfiguration per Textdatei, die Syntax braucht etwas Eingewöhnung.
  • Nginx Proxy Manager — Nginx mit Klick-Oberfläche obendrauf. Neuen Dienst eintragen dauert dreißig Sekunden im Browser. Bei Einsteigern entsprechend beliebt.
  • Caddy — winzige Konfigurationsdatei, und um HTTPS-Zertifikate kümmert er sich bei öffentlichen Domains komplett von selbst.
  • Traefik — konfiguriert sich über Docker-Labels quasi automatisch, dafür ist die Lernkurve steiler. Eher was für später.

Mini-Praxis: Caddy in fünf Minuten

Grau ist alle Theorie, also bauen wir das Ding einmal auf. Wir nehmen Caddy, weil die Konfiguration am kürzesten ist. Voraussetzung: Docker läuft, und mindestens ein Dienst mit Weboberfläche auch (im Beispiel Uptime Kuma auf Port 3001 und Immich auf 2283 — ersetze das einfach durch deine Dienste). Erst Ordner und Konfigurationsdatei anlegen:

mkdir -p ~/caddy/conf
cd ~/caddy
nano conf/Caddyfile

In die Datei kommen die Türsteher-Regeln (ersetze 192.168.1.20 überall durch die IP deines Servers):

http://uptime.heim.lan {
	reverse_proxy 192.168.1.20:3001
}

http://fotos.heim.lan {
	reverse_proxy 192.168.1.20:2283
}

Das http:// vorne ist Absicht: Caddy würde sonst automatisch HTTPS-Zertifikate besorgen wollen, und das klappt nur mit einer echten, öffentlich erreichbaren Domain. Im reinen Heimnetz starten wir deshalb erstmal unverschlüsselt. Falls du eine eigene Domain besitzt: Trag sie statt der http://…-Zeile ein, den Rest erledigt Caddy allein.

Jetzt die compose.yaml daneben legen (Aufbau wie in der offiziellen Caddy-Doku):

services:
  caddy:
    image: caddy:2
    restart: unless-stopped
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./conf:/etc/caddy
      - caddy_data:/data
      - caddy_config:/config

volumes:
  caddy_data:
  caddy_config:

Und starten:

docker compose up -d

Fehlt noch ein Detail: Die Namen uptime.heim.lan und fotos.heim.lan muss dein Netz erstmal kennen.

Lokales DNS? Das Telefonbuch deines Heimnetzes: Es übersetzt Namen in IP-Adressen. Diese Rolle übernimmt dein Router (viele Modelle können eigene Einträge), ein Pi-hole/AdGuard Home — oder zum schnellen Testen die hosts-Datei deines Rechners.

Für den Schnelltest reicht die hosts-Datei (/etc/hosts unter Linux und macOS, C:\Windows\System32\drivers\etc\hosts unter Windows). Eine Zeile genügt:

192.168.1.20  uptime.heim.lan fotos.heim.lan

Dann im Browser http://uptime.heim.lan aufrufen — und da ist Uptime Kuma, ganz ohne Portnummer. Dein erster Reverse Proxy läuft.

Häufige Stolpersteine

  • Caddy startet nicht, Port 80 ist belegt. Dann lauscht dort schon etwas anderes, gern das Webinterface eines Pi-hole. Wie du den Schuldigen findest, steht im Port-belegt-Beitrag.
  • 502 Bad Gateway. Der Proxy läuft, aber das Ziel antwortet nicht: IP und Port im Caddyfile prüfen, und läuft der Dienst überhaupt? Beliebte Falle: localhost im Caddyfile meint den Caddy-Container selbst, nicht deinen Server. Deshalb steht im Beispiel die Server-IP.
  • Der Name löst nicht auf. DNS-Eintrag vergessen, oder das Gerät nutzt einen anderen DNS-Server (Smartphones machen das gern mal am Router vorbei). Die hosts-Datei ist der zuverlässigste Gegencheck.
  • Der Browser springt stur auf https://. Viele Browser probieren HTTPS zuerst. Das http:// explizit mittippen, oder gleich mit echter Domain und automatischen Zertifikaten arbeiten.

Fazit

Meine Einschätzung: Bei zwei Diensten ist ein Reverse Proxy noch Luxus. Ab drei wird er zur Lebensqualität, und spätestens wenn HTTPS oder Zugriff von unterwegs ansteht, führt kein Weg mehr an ihm vorbei. Dann ist die eine, gut gesicherte Tür jedem Flickenteppich aus Portfreigaben überlegen. Einsteigern würde ich Caddy oder den Nginx Proxy Manager empfehlen; Nginx pur und Traefik laufen dir später noch früh genug über den Weg. Und das Schöne: Deine Dienste merken von alledem nichts, du kannst den Proxy jederzeit gefahrlos nachrüsten.

Wie läuft das bei dir: Tippst du noch IP und Port aus dem Gedächtnis, hängt alles in Bookmarks, oder steht längst ein Türsteher vor deinen Diensten? Und falls ja: Team Konfigdatei oder Team Klick-Oberfläche? Schreib's in die Kommentare.

One more thing … solche Grundlagen-Erklärer erscheinen hier jetzt regelmäßig. Wenn du den nächsten nicht verpassen willst: Trag dich unten kurz für den Newsletter ein, neue Beiträge landen dann direkt in deinem Postfach. Kein Spam, versprochen.

Quellen