Reverse Proxy im Homelab

Ein Homelab sammelt Weboberflächen wie eine Kramschublade Kabel – und keiner weiß mehr, welcher Port was öffnet. Ein Reverse Proxy gibt jedem Dienst einen ordentlichen Namen und stellt alle hinter eine gemeinsame Tür.

Kurz gesagt

Ein Reverse Proxy ist ein einzelner Dienst, der alle Webanfragen annimmt, liest, welchen Namen der Client angefragt hat, und die Anfrage an den passenden Dienst dahinter weiterreicht. Er beendet außerdem die Verschlüsselung an einer Stelle, sodass Du Zertifikate einmal verwaltest statt pro Dienst. Er ist eine gute Eingangstür, aber allein noch kein vollständiges Sicherheitskonzept.

So funktioniert’s

1. Reverse oder Forward. Ein Forward Proxy arbeitet im Auftrag der Clients: Der Client weiß von ihm und nutzt zum Beispiel die Methode CONNECT, um externe Seiten zu erreichen. Ein Reverse Proxy arbeitet im Auftrag der Server: Clients wissen nichts von ihm und sprechen einfach mit etwas, das wie der Dienst aussieht [5]. Im Homelab willst Du fast immer die zweite Art – eine Adresse, viele Dienste dahinter. Für diesen Guide nehmen wir an, dass Namen wie dienst.homelab.example bereits auf den Proxy zeigen; wie das funktioniert, behandelt unser Artikel zur DNS-Namensauflösung.
2. TLS endet am Proxy, der Name wählt die Route. TLS selbst kann dem Server nicht mitteilen, welchen Server der Client sucht. Diese Lücke schließt die SNI-Erweiterung: RFC 6066 beschreibt sie für Server, die mehrere virtuelle Server hinter einer Netzwerkadresse betreiben, und sagt, ein Server darf sie nutzen, um das Zertifikat auszuwählen [13]. Innerhalb der verschlüsselten Verbindung trägt der HTTP-Header Host den Namen noch einmal, und der Proxy wählt damit das Backend. Die Caddy-Dokumentation nennt beide Werte als Grundlage, mit der Server routen und Zertifikate auswählen [1]. Nach der Terminierung spricht Caddy standardmäßig unverschlüsseltes HTTP mit dem Backend [1]. NIST SP 800-207 hält fest, dass der Netzwerkort allein kein Vertrauen begründet und Kommunikation unabhängig vom Ort gesichert sein soll [14]. Entscheide deshalb pro Dienst, ob auch der letzte Abschnitt TLS braucht, und beachte, dass ein https://-Upstream einen passenden Host-Wert brauchen kann [1].
3. Zertifikate für interne Namen, Weg eins: öffentliche CA mit DNS-01. ACME (RFC 8555) ist das Protokoll, das den Nachweis der Namenskontrolle und die Ausstellung des Zertifikats automatisiert [11]. Let’s Encrypt bietet HTTP-01, das Port 80 aus dem Internet braucht und keine Wildcards ausstellt, und DNS-01, das die Kontrolle über einen TXT-Eintrag belegt, Wildcards unterstützt und auch für nicht erreichbare Server funktioniert [9]. Öffentliche CAs stellen nur für Namen aus, die Du wirklich kontrollierst: Caddy führt localhost, .local, .internal und .home.arpa unter den Namen auf, die nicht für öffentlich vertrauenswürdige Zertifikate infrage kommen [2]. Interne Dienste brauchen also Namen unter einer Domain, die Dir gehört. Die Abwägung: DNS-01 braucht API-Zugangsdaten für Deinen DNS-Anbieter, und Let’s Encrypt warnt, dass volle Zugangsdaten auf einem Webserver den Schaden bei einer Übernahme vergrößern; empfohlen werden eng begrenzte Zugangsdaten, ein separater Validierungsserver oder die Delegation von _acme-challenge per CNAME [9]. Ausgestellte Zertifikate werden öffentlich protokolliert, und Let’s Encrypt verweist dafür auf Suchwerkzeuge für Certificate Transparency [10]. Nach unserer Lesart hält ein Wildcard-Zertifikat die einzelnen Dienstnamen aus dem Zertifikat heraus. Auch der Zertifikats-Resolver von Traefik dokumentiert diese DNS-Challenge samt CNAME-Delegation [8]. Achte auf die Rate Limits: Stand 18. Okt. 2026 laut Let’s Encrypt (Seite zuletzt aktualisiert am 5. Aug. 2026) gelten 5 Zertifikate pro identischer Namensmenge und 50 pro registrierter Domain je 7 Tage, und eine Staging-Umgebung hat höhere Grenzen [10]. Auch Caddy rät, gegen Staging zu testen [2].
4. Weg zwei: eine eigene CA. Caddy kann eine lokale CA mit Root und Intermediate erzeugen; die Endzertifikate signiert das Intermediate. Das nutzt weder ACME noch DNS-Validierung, und es gilt nur dort, wo der Root installiert ist [2]. Nach den dokumentierten Standardwerten von Caddy hält der Root 10 Jahre, das Intermediate 7 Tage und ein Endzertifikat 12 Stunden [3]. Caddy versucht, den Root in den Zertifikatspeicher des eigenen Rechners einzutragen, doch das kann in Containern oder unter einem unprivilegierten Benutzer scheitern; dann führst Du caddy trust aus oder kopierst den Root von Hand heraus [3]. Den Root auf weitere Geräte zu bringen, ist Deine Aufgabe als Administrator [2]. Jeder Client ohne den Root zeigt Sicherheitsfehler [2]. Und weil ein vertrauenswürdiger Root auf jedem Gerät, das ihm vertraut, für beliebige Namen bürgen kann, schützt Du seinen Schlüssel. Caddy nennt das Vertrauen darauf sicher, solange der Rechner nicht kompromittiert ist und der Schlüssel nicht abfließt [2].
5. Weiterleitungs-Header und WebSockets. Hinter einem Proxy sieht das Backend den Proxy als Client. RFC 7239 beschreibt diesen Informationsverlust und definiert den Header Forwarded mit den Parametern by, for, host und proto; er nennt den Header optional und sensibel und sagt, er solle standardmäßig ausgeschaltet sein [12]. Die älteren X-Forwarded-For, X-Forwarded-Proto und X-Forwarded-Host sind die verbreiteten, nicht standardisierten Varianten [12]. Caddy setzt alle drei standardmäßig und ignoriert eingehende Werte, außer sie stammen von Adressen, die Du als trusted_proxies einträgst [1]. Traefik kennt forwardedHeaders.trustedIPs pro Entry Point und dokumentiert seinen insecure-Modus nur für Tests [7]. Bei nginx wird der ursprüngliche Host nicht standardmäßig weitergegeben; der Backend-Server bekommt $proxy_host, außer Du setzt proxy_set_header Host $host; [6]. WebSockets brauchen zusätzliche Sorgfalt: Upgrade und Connection sind Hop-by-Hop-Header, also braucht nginx proxy_set_header Upgrade $http_upgrade; und einen passenden Connection-Header, und es schließt ruhende Tunnel standardmäßig nach 60 Sekunden [5]. Caddy unterstützt WebSockets selbst, schließt sie aber bei einem Neuladen der Konfiguration, solange Du stream_close_delay nicht setzt [1].
6. Typische Fehlerbilder. Redirect-Schleifen entstehen oft, wenn das Backend nur unverschlüsseltes HTTP sieht, den Besuch für unsicher hält und immer wieder auf HTTPS umleitet. Prüfe, ob der Proxy das ursprüngliche Schema und den Host mitsendet und ob die App dem Proxy vertrauen soll. Zeigen die Logs nur die Proxy-Adresse als Client, fehlen die Weiterleitungs-Header oder das Backend vertraut ihnen nicht. Zertifikatswarnungen haben meist eine von drei Ursachen: Der CA-Root ist auf diesem Client nicht vertrauenswürdig, der Name im Browser steht nicht im Zertifikat, oder jemand hat den Dienst per IP-Adresse aufgerufen. RFC 6066 weist darauf hin, dass eine Abweichung zwischen angefragtem und zertifiziertem Namen auffällt, wenn der Client die Identität des Servers prüft [13].
7. Sicherheit: ein Eintrittspunkt heißt ein Ziel. Alles über einen Proxy zu führen, vereinfacht Logs, Zertifikate und Updates. Es heißt aber auch, dass dieser Proxy das Erste ist, was ein Angreifer sieht – halte seine Software aktuell. Leite nur die Ports weiter, die der Proxy braucht, und halte Verwaltungsoberflächen wie NAS- oder Hypervisor-Konsolen aus dem öffentlichen Zugriff heraus. Lass Backends nur Verkehr vom Proxy annehmen, sonst lässt sich der Proxy umgehen – das ist unsere Empfehlung, kein Zitat aus einer Quelle. Eine Vorab-Prüfung kann einen Login vor eine App setzen: Caddys forward_auth schickt eine Kopie der Anfrage an ein Authentifizierungs-Gateway, macht bei einer 2xx-Antwort weiter und gibt sonst die Antwort des Gateways, meist eine Weiterleitung zum Login, an den Client zurück [4]. Behandle Logs als sensible Daten; RFC 7239 selbst nennt die Client-Angaben in Weiterleitungs-Headern sensibel [12].
8. Der Zero-Trust-Bezug, sachlich. In NIST SP 800-207 ermöglicht, überwacht und beendet ein Policy Enforcement Point Verbindungen zwischen einem Subjekt und einer Ressource, und er kann eine Gateway-Komponente vor der Ressource sein [14]. Ein Reverse Proxy kann diese Rolle übernehmen. Dasselbe Dokument erwartet, dass eine Organisation Identitäts-, Berechtigungs- und Zugriffsverwaltung sowie Inventarverwaltung betreibt, und beschreibt Zugriff als Entscheidung pro Sitzung nach dynamischer Richtlinie, die den Zustand von Identität und Gerät einbezieht [14]. Ein Reverse Proxy allein liefert nichts davon. Nach unserer Lesart ist er ein möglicher Durchsetzungspunkt, aber kein Ersatz für Identitäten, ein Inventar oder festgelegte Richtlinien.

Ein Homelab-Beispiel

In unserem Homelab bei Bytearium gibt es eine interne Zertifizierungsstelle auf Basis von „Caddy Local Authority 2026 ECC Root“. Das Zertifikat ist auf einem Arbeitsrechner vorbereitet, aber noch nicht als systemweit vertrauenswürdig eingetragen (Stand 14.–18.10.2026). Solange dieser Schritt fehlt, würden Clients, die den Zertifikatspeicher des Systems nutzen, bei Zertifikaten dieser CA warnen – Vertrauen ist genau das, was der Root liefert [2]. Wir behandeln das als offene Aufgabe, nicht als erledigte Arbeit. Hosts und Dienste nennen wir hier nicht.

Ein allgemeines Beispiel mit Platzhalter-Domain: In Caddy schreibst Du einen Site-Block mit der Adresse dienst.homelab.example und darin zwei Zeilen, tls internal und reverse_proxy backend:8080 [1][3]. Damit wird der Dienst per HTTPS mit einem Zertifikat der lokalen CA ausgeliefert, und Anfragen gehen an das Backend namens backend. Willst Du lieber eine öffentliche CA, ersetzt Du die erste Zeile durch einen tls-Block mit dns und dem Namen Deines Anbieters [3]. Das ist eine Veranschaulichung, keine aufgezeichnete Ausgabe.

Prüfliste

• Prüfe, ob jeder interne Name auf den Proxy zeigt und nicht auf die einzelnen Backends.
• Entscheide, ob Du eine öffentliche CA mit DNS-01 oder eine eigene CA nutzt, und halte den Grund schriftlich fest.
• Prüfe, ob jedes Client-Gerät, auch Handys und Container, Deinem eigenen Root vertraut, bevor Du ihn ausrollst.
• Begrenze die DNS-API-Zugangsdaten auf die nötigen TXT-Einträge oder delegiere _acme-challenge an eine separate Zone.
• Teste die Zertifikatsausstellung zuerst gegen einen Staging-Endpunkt, damit Du die Rate Limits nicht erreichst.
• Prüfe, ob das Backend Schema, Host und Client-Adresse im Original bekommt und ob es diesen Headern nur vom Proxy glaubt.
• Teste WebSocket-Seiten und prüfe Leerlauf-Timeouts sowie das Verhalten beim Neuladen der Konfiguration.
• Prüfe, dass Verwaltungsoberflächen nicht aus dem Internet erreichbar sind und Backends nur Verkehr vom Proxy annehmen.
• Aktualisiere den Proxy regelmäßig, lies seine Logs, und halte schriftlich fest, welchen Teil von Zero Trust Du abdeckst und welchen nicht.