Reverse Proxy im Homelab: Welche Software passt wirklich?

Jeder, der einmal mehr als einen Dienst zu Hause oder im kleinen Büro betreibt, stolpert über dasselbe Problem: Plötzlich haben Pi-hole, Nextcloud, Jellyfin und ein Dashboard 각자 eine eigene IP-Adresse, jeder mit seinem eigenen Self-Signed-Zertifikat, jeder mit einem Browser-Warnfenster, das jeden Besucher erschreckt. Dann kommt der Gedanke: „Ich brauche einen Reverse Proxy." Und meistens folgt sofort der typische Fehler.

Der Fehler, mit dem fast jeder anfängt

Der typische Fehlschluss lautet: Ein Reverse Proxy ist nur ein Zertifikat-Trick. Man installiert irgendwas, hinterlegt ein Let's Encrypt-Zertifikat, leitet Port 443 weiter, und der Rest funktioniert von selbst. Das stimmt nicht. Ein Reverse Proxy ist in Wahrheit ein Verkehrsleiter, ein Übersetzer und ein Gatekeeper in einem. Wer ihn nur als Zertifikats-Halter versteht, bekommt plötzlich Subdomain-Routing-Probleme, Authentifizierungsketten, die nicht funktionieren, und Konfigurationen, die nach einem Update plötzlich alle Dienste abschneiden. Der Proxy entscheidet, welcher Dienst wann erreichbar ist – und wenn er falsch konfiguriert ist, ist das Ausmaß des Problems weit größer als eine einzige fehlerhafte HTTPS-Verbindung.

Was ein Reverse Proxy im Homelab eigentlich macht

In einem Homelab mit mehreren Diensten erfüllt ein Reverse Proxy vier Hauptaufgaben:

TLS-Terminierung. Der Proxy ist der einzige Dienst, der nach außen ein gültiges Zertifikat präsentiert. Nach innen kommuniziert er oft klartext mit den Backend-Diensten – HTTPS ist nur zwischen nutzer und proxy. Das spart jedem einzelnen Dienst die Zertifikatsverwaltung und zentralisiert Erneuerungen.

Routing. Der Proxy schaltet eingehende Anfragen auf Grundlage von Hostname, Pfad oder Port auf ein oder mehrere Backend-Dienste um. cloud.beispiel.de geht zu Nextcloud, media.beispiel.de zu Jellyfin, pi.beispiel.de zu Pi-hole. Ohne diesen Schalter müsste jeder Dienst einen eigenen Port und eigenen Eintrag in der Firewall haben.

Subdomains als Zugriffsmodell. Statt viele IPs oder viele hohe Ports (8080, 8443, 9090) nutzt man eine Adresse mit mehreren Subdomains. Das ist nicht nur übersichtlicher, sondern auch sicherer: Jeder Dienst wird über eine klar definierte Domäne erreicht, nicht über irgendeine IP mit Portnotiz.

Authentifizierung – optional, aber häufig der Grund für die Wahl. Manche Proxies lassen sich um eine Vorauthentifizierung erweitern: Benutzer müssen sich gegenüber dem Proxy identifizieren, bevor sie überhaupt das Backend erreichen. Das ist besonders relevant für nicht-öffentliche Dienste. Ob das nativ im Proxy oder durch ein eigenständiges Auth-Tool (Authelia, Zitadel) passiert, hängt davon ab, welche Software man wählt.

Vergleichstabelle: Die relevanten Kriterien

In einer Familie, in der mehrere Personen Dienste betreuen, zählt nicht nur raw performance – sondern ob jemand nach einem Update die Konfiguration noch verstehen kann. Die Tabelle listet Kriterien auf, die im Homelab real zuginschlägig sind, nicht im Enterprise-Szenario.

|---|---|---|---|---|

| Automatisches HTTPS | Ja, standardmäßig aktiv, Let's Encrypt inklusive Wildcard-Unterstützung | Ja, über Let's Encrypt-Provider oder externe Zertifikats-Quelle | Ja, per UI-Button oder automatische Domain-Erkennung | Nein – Zertifikatsregeneration muss konfiguriert werden (ACME-Modul oder extern) |

| Konfigurationsaufwand | Sehr niedrig – Caddyfile ist oft 5–10 Zeilen für mehrere Dienste | Mittel – Docker-Labels oder YAML-Traefik.toml; lernt man mit Labels am schnellsten | Niedrig bis Mittel – UI-basiert, aber man muss im Hintergrund verstehen, was die UI eigentlich schreibt | Hoch – Konfiguration ist textbasiert, keine automatische HTTPS-Erweiterung |

| Docker-Tauglichkeit | Ja – über Docker-Labels oder manuelles Caddyfile; kein automatisches Discovery ohne Konfiguration | Sehr gut – Docker-Provider erkennt Container-Labels automatisch, das ist Traefiks Kern-Stärke | Ja – Container-Variante verfügbar, aber der Hauptweg ist die UI-Installation | Teilweise – als Container lauffähig, aber Discovery muss eingerichtet werden |

| Proxmox-Tauglichkeit | Yes – als LXC oder VM, keine Sonderanforderungen | Yes – als LXC/VM oder Container | Yes – gebräuchlichste Variante ist VM/LXC mit npm-Paket oder Docker-Container | Yes – als LXC/VM; Skalierungsrelevanz erst ab höheren Lasten |

| Ausfallrisiko bei Fehlkonfiguration | Gering – Caddy verweigert oft zu starten bei Syntaxfehlern; kein Stillstand bestehender Verbindungen bei Reload | Mittel – ungültige TLS-Konfiguration blockiert Neustart; Labels-Fehler können einzelne Routen betreffen | Mittel – UI-basierte Fehler können einzelne Proxy-Hosts betreffen, aber meist isoliert | Hoch – eine falsche ACL oder Map-Datei kann alle Dienste aussperren; kein UI-Rückfall |

| UI vorhanden | Nein (CLI/Konfigurationsdatei) | Nein (Dashboard optional, keine Produktions-UI für Konfiguration) | Ja – vollständige Web-Oberfläche für Proxy-Hosts, Zertifikate, Einstellungen | Nein (in der Basisversion); das HAProxy-Enterprise-Add-on „Aloha" hat eine UI |

| Dokumentationslage | Sehr gut – offizielle Dokumentation umfangreich und aktuell; Caddyfile-Syntax klar beschrieben | Gut – Dokumentation liegt vor, aber die Vielzahl an Provider-Optionen erfordert gezielte Recherche | Gut – schriftlich vorhanden, aber die UI ist selbsterklärender; Community-Foren stark | Gut – sehr detaillierte Referenz Dokumentation, aber Nicht-Administratoren brauchen Einarbeitungszeit |

Je Proxy: Stärken und Schwächen für Nicht-Administratoren

Caddy – der Einsteiger, der ernst genommen wird

Stärken: Caddy liefert von Haus aus HTTPS. Wenn man caddy reverse-proxy mit einer Domain konfiguriert, generiert Caddy automatisch ein Let's Encrypt-Zertifikat – sofern die Domain von außen erreichbar ist. Die Syntax ist auf geraden Rails: Ein Caddyfile mit drei bis fünf Zeilen deckt mehrere Dienste ab. Wildcard-Zertifikate funktionieren, wenn der DNS-Challenge-Weg (über einen DNS-Provider-Plugin) korrekt konfiguriert ist. Caddy ist auch relativ robust wenn eine einzelne Route falsch ist – oft schaltet er nur diese Route ab, nicht alle.

Schwächen: Keine grafische Oberfläche. Wer mit Konfigurationsdateien nicht zurechtkommt, wird es schwierig. Der Auto-HTTPS-Mechanismus setzt voraus, dass die Domain von außen erreichbar ist – in rein lokalen Netzwerken ohne öffentliche IP funktioniert er nicht ohne eigene CA. Und Caddy hat keinen eingebauten Path-basierten Authentifizierungsschalter, den man per UI aktivieren kann – man braucht für Vorauthentifizierung etwas wie Authelia.

Traefik – der Container-Vereinsehler

Stärken: Traefik ist für Docker-Umgebungen konzipiert. Wenn Services containerisiert sind und die richtigen Labels tragen, erkennt Traefik sie automatisch und leitet Traffic entsprechend um. Kein manuelles Konfigurieren neuer Routen für jeden neuen Container. HTTPS über Let's Encrypt ebenfalls automatisch. Die dynamische Konfiguration spart Zeit, wenn man regelmäßig Dienste hinzufügt oder entfernt.

Schwächen: Die automatische Erkennung ist nur so gut wie die Labels – falsche Labels bedeuten, dass Dienste nicht erreichbar sind, ohne dass Traefik eine Fehlermeldung liefert, die für Einsteiger aussagekräftig ist. Die Konfigurationssyntax (YAML oder TOML) ist für nicht-vertraute Personen kryptischer als Caddyfile. Traefik hat keine Konfigurations-UI, das ist bewusst so gewollt, aber es bedeutet, dass jede Änderung über Konfigurationsdateien oder Labels läuft. Und wie Caddy benötigt Traefik eine von außen erreichbare Domain für automatische Zertifikate.

Nginx Proxy Manager – der mit der Klick-Oberfläche

Stärken: NPM hat eine Web-Oberfläche, in der man Proxy-Hosts, Zertifikate, SSL-Einstellungen und Forwarding-Regeln per Maus klickt. Das ist für Personen, die mit CLI nicht vertraut sind, am anschaulichsten. Zertifikate lassen sich per UI anfordern und verwalten. Die Fehlersuche ist sichtbarer als bei reinen Konfigurationsdateien, weil man im UI sieht, welche Regeln aktiv sind.

Schwächen: NPM basiert auf Nginx, und wer nicht versteht, was Nginx eigentlich tut, hat trotz UI Grenzen beim Debuggen. Die automatische Zertifikat-Erneuerung funktioniert gut, aber man muss die Domains von außen erreichbar machen – genau wie bei allen anderen Lösungen. NPM ist auch etwas weniger flexibel als reines Nginx bei spezielleren Konfigurationsanforderungen. Und wenn NPM selbst in einen Fehlerzustand gerät (z.B. durch Hardware-Problem), stehen alle hinter ihm liegenden Dienste nicht mehr zur Verfügung.

HAProxy – der leistungsstarke, stoische Klassiker

Stärken: HAProxy ist extrem stabil, effizient und skaliert auch unter Last gut. Für reines Routing, Lastverteilung oder Echofilterung ohne grafische Oberfläche gut geeignet. Die Konfiguration ist textuell, aber sehr konsistent – wer sie einmal versteht, kann viele Variationen bauen. RAM-Bedarf ist niedrig; selbst auf schwächeren Systemen läuft HAProxy zuverlässig.

Schwächen: Kein automatisches HTTPS aus der Box – Zertifikate müssen separat beschafft und konfiguriert werden. Keine grafische Oberfläche (außer im kostenpflichtigen Enterprise-Varianten, die für das Homelab eigentlich nicht relevant ist). Die Einstiegshürde ist hoch: Syntax, ACL-Regeln, Map-Dateien – das erfordert Lernaufwand. Für jemanden, der „ich will einfach HTTPS und Subdomains ohne Systemhandwerkszeug" will, ist HAProxy meist nicht die erste Wahl.

Entscheidungsregeln – welche Software wann passt

Nimm Caddy wenn: Du hast keine grafische Oberfläche nötig, Konfigurationsdateien sind okay, und du willst das geringste Setup für HTTPS + mehrere Dienste. Caddy ist die smarte Wahl, wenn du nur ein einziges Config-File pflegst und nicht täglich neue Container hinzufügst. Ideal für: VM- oder LXC-Installation, nicht primär Container-lastig.

Nimm Traefik wenn: Dein gesamtes Homelab auf Docker läuft und du willst, dass neue Container automatisch erkannt werden. Traefik passt sich dynamisch an – das spart Konfigurationsaufwand bei fluktuierender Dienstlandschaft. Ideal für: Docker-basiertes Homelab, regelmäßige Dienständerungen.

Nimm Nginx Proxy Manager wenn: Du eine grafische Oberfläche willst, keine Konfigurationsdateien tippen möchtest, und deine Dienste nicht täglich wechseln. NPM ist die Option für Personen, die per Maus klicken können und eine nachvollziehbare Übersicht über Regeln wollen. Ideal für: Einsteiger, die CLI vermeiden wollen, statische Dienstlandschaft.

Nimm HAProxy wenn: Du maximale Stabilität, niedrige Ressourcennutzung und detaillierte Kontrolle über Routing-Regeln brauchst und Bereitschaft zur Text-Konfiguration hast. HAProxy ist kein Einsteiger-Tool, aber für jemanden, der Nginx/HAProxy-Syntax sowieso kennt, ist es eine solide Wahl. Ideal für: Erfahrene Nutzer, Leistungskritische Szenarien, keine UI nötig.

Typische Fehlschlüsse – was nach der Installation schiefgehen kann

Falsche Wildcard-DNS. Eine Wildcard-DNS-Konfiguration bedeutet, dass *.meinedomain.de auf dieselbe IP zeigt. Aber eine Wildcard-Zertifikatsanfrage (Let's Encrypt) funktioniert nur, wenn der DNS-Challenge-Mechanismus korrekt konfiguriert ist – nicht jede DNS-Provider-Integration funktioniert out-of-the-box. Ein Wildcard-Subdomain, das nicht korrekt in der DNS-Kette aufgelöst wird, führt dazu, dass der Browser die Verbindung verweigert, obwohl auf dem Server alles korrekt läuft.

Zertifikat für die interne IP statt für die Domain. Ein Zertifikat, das eine IP-Adresse (z.B. 192.168.3.25) als Common Name hat, wird von Browsern für öffentliche Domänen nicht akzeptiert. Das Zertifikat muss die Domain enthalten, unter der der Dienst erreichbar ist. Wenn jemand in seinen Proxy-Einstellungen die externe Domain eintragen und das Zertifikat dennoch die lokale IP bestätigt, stimmt etwas grundlegend falsch.

Port 443 schon durch einen anderen Dienst belegt. Wenn Nginx oder Apache oder ein anderer Webserver bereits Port 443 nutzt, kann der Reverse Proxy nicht gleichzeitig auf denselben Port hören. Der Proxy muss den Port übernehmen – was bedeutet, dass der andere Dienst entweder auf einen anderen Port verschoben oder deaktiviert wird. Diese Konflikte fallen meist zu Installationszeitpunkt auf, aber wer die Firewall-Einträge nur teilweise überprüft, bekommt sie später als „Plötzlich funktioniert nichts mehr"-Problem.

Zertifikats-Autor aus dem falschen Land. Let's Encrypt ist eine weit verbreitete, gebräuchliche CA. Wenn ein alternativer Zertifikats-Aussteller gewählt wird, der von Browsern oder Betriebssystemen nicht vertraut wird, wird die Verbindung abgelehnt – unabhängig davon, ob der Proxy technisch korrekt funktioniert. Der Zertifikats-Aussteller muss in den üblichen Browser-Trust-Store-Listen enthalten sein. Bei eigenen CAs gilt das natürlich nicht, aber dann gilt die Einschränkung: Nur innerhalb des eigenen Netzwerks.

Eigene PKI und interne CA – wenn der Dienst nicht ins Internet geht

Wenn kein Dienst von außen erreichbar ist – etwa weil das Homelab ausschließlich im lokalen Netzwerk betrieben wird und keine öffentliche IP vorhanden ist – funktionieren automatische Zertifikatsmechanismen (Let's Encrypt etc.) nicht direkt. Dann gibt es zwei Wege:

Eigener Zertifikatsauthorität (CA). Man erstellt eine eigene CA, signiert die Dienst-Certificates mit ihr, und verteilt das Root-Zertifikat der CA auf alle Geräte, die die Dienste nutzen sollen. Das ist technisch machbar, erfordert aber Aufwand bei der Verteilung und Wartung. Für einen einzelnen Rechner im Homelab oft übertrieben.

Selbst signierte Zertifikate pro Dienst. Einfacher, aber weniger elegant: Jeder Proxy und jeder Dienst bekommt ein eigenes selbstsigniertes Zertifikat. Clients (Browser, Clients) akzeptieren diese nicht ohne manuelle Ausnahme-Regelung. Das reicht für Testzwecke, aber es ist keine nachhaltige Lösung.

Der CI/CD-Pfad für eine eigene CA existiert – Werkzeuge wie step-ca oder eigene OpenSSL-Skripte bieten das. Aber für die meisten Homelaber, die doch erreichbar sind, ist automatisches Let's Encrypt über den Proxy die deutlich einfachere Option.

FAQ

Was ist der Unterschied zu einem Cloudflare Tunnel?

Ein Reverse Proxy läuft selbst – auf der eigenen Hardware, in der eigenen Verantwortung. Ein Cloudflare Tunnel (oder vergleichbare Tunnel-Lösungen) leitet Traffic aus dem eigenen Netzwerk durch einen externen Dienst (hier: Cloudflare) nach außen. Der Vorteil eines Tunnels: Keine eigene öffentliche IP, keine Portfreigabe in der Firewall nötig. Der Nachteil: Traffic läuft über einen externen Dienst, der Anbieter hat Zugriff auf den Verkehr, und wenn der Dienst Probleme hat, sind auch die eigenen Dienste betroffen. Ein Reverse Proxy bietet volle Kontrolle, erfordert aber eine öffentliche Erreichbarkeit der eigene Domäne. Die Entscheidung hängt davon ab, ob man auf einen externen Vermittler vertrauen will oder nicht.

Kann ich mehrere Reverse Proxies parallel betreiben?

Technisch ja, aber es bringt meist kein Problem lösen, sondern verschiebt es. Zwei Proxies, die gleichzeitig Port 443 hören wollen, bekommen einen Konflikt. Parallel-Betrieb macht nur Sinn, wenn sie unterschiedliche Ports hören, oder wenn einer für bestimmte Subdomains zuständig ist und der andere für andere – das ist aber selten eine gute Architektur für kleine Homelab. Ein Proxy, der Konflikte vermeidet, ist der praktischere Weg.

Was passiert, wenn Let's Encrypt-Zertifikat abgelaufen ist?

Wenn der Proxy so konfiguriert ist, dass er automatisch Erneuerungen durchführt, passiert in der Regel nichts – der Proxy erneuert im Hintergrund. Wenn die Automatisierung nicht funktioniert (z.B. weil DNS- oder HTTP-Challenge nicht korrekt aufgesetzt ist), bekommt der Nutzer nach Ablauf eine Browser-Warnung. Der Dienst ist nicht ausgefallen, aber nicht mehr ohne Warnung aufrufbar. Daher lohnt es sich, den Erneuerungsmechanismus einmalig zu testen und zu verifizieren, dass er auch ohne manuellen Eingriff funktioniert.

Braucht jeder Dienst hinter dem Proxy HTTPS?

Nein. Wenn der Proxy TLS terminiert, kann er im Inneren klartext (HTTP) mit den Backend-Diensten kommunizieren – solange der Vertrauensweg innerhalb des eigenen Netzwerks liegt. Das ist der Hauptvorteil einer zentralisierten TLS-Terminierung: Jeder Dienst muss sich nicht um Zertifikate kümmern. Wenn das Netzwerk nicht vollständig vertrauenswürdig ist – etwa weil ein Gerät im Netzwerk kompromittiert sein könnte – wäre Ende-zu-Ende-HTTPS zwischen Proxy und Backend empfehlenswerter. Für das typische Homelab reicht HTTP hinter dem Proxy.

Hinweis: Dieser Artikel ist redaktioneller Inhalt und enthält keine Affiliate- oder Partner-Links. Alle Angaben entsprechen dem Stand 2026 und können sich ändern.