Irgendwann passiert es.
Man hat ein Homelab.
Erst nur ein NAS.
Dann ein kleiner Mini-PC.
Dann Docker.
Dann ein paar Dienste.
Dann noch ein Dashboard.
Dann ein Passwortmanager.
Dann ein Git-Server.
Dann eine Fotoverwaltung.
Dann irgendein Tool, das man eigentlich nur testen wollte, das aber jetzt seit acht Monaten produktiv läuft, weil man emotional zu schwach war, es wieder zu löschen.
Und plötzlich steht man da mit URLs wie:
http://192.168.178.42:8080
http://192.168.178.42:3000
http://192.168.178.42:9000
http://192.168.178.43:8123
Sehr schön.
Sehr professionell.
Sehr „Ich habe die Kontrolle verloren, aber immerhin läuft es“.
Dann kommt der Moment, in dem man sich denkt:
Das müsste doch auch hübscher gehen.
Also zum Beispiel:
https://vault.example.de
https://photos.example.de
https://home.example.de
https://git.example.de
Und genau da kommt der Reverse Proxy ins Spiel.
Der Reverse Proxy ist der Türsteher deines Homelabs.
Er steht vorne an der Tür, nimmt Anfragen entgegen, schaut auf den Namen, entscheidet, welcher Dienst gemeint ist, und leitet die Anfrage weiter.
Wenn er gut konfiguriert ist, merkt niemand etwas.
Wenn er schlecht konfiguriert ist, sitzt du nachts um 00:37 Uhr vor Logs, die so hilfreich sind wie ein Drucker mit Bindungsangst.
Inhaltsverzeichnis
- Was ist ein Reverse Proxy?
- Forward Proxy vs. Reverse Proxy
- Warum man das im Homelab will
- Domains, Subdomains und DNS
- TLS-Zertifikate und HTTPS
- Ports und die kleine Hölle der Freigaben
- Caddy: Der bequeme Weg
- Nginx: Der Klassiker mit Kanten
- Docker-Compose-Beispiel
- Typische Fehler
- Sicherheit: Nur weil es geht, muss es nicht ins Internet
- Fazit
1. Was ist ein Reverse Proxy?
Ein Reverse Proxy ist ein Server, der Anfragen von außen entgegennimmt und intern an den richtigen Dienst weiterleitet.
Stell dir vor, du hast mehrere Dienste im Heimnetz:
- Passwortmanager auf Port 8080
- Fotoverwaltung auf Port 2283
- Dashboard auf Port 3000
- Home Assistant auf Port 8123
Natürlich könntest du jeden Dienst direkt erreichbar machen.
Natürlich könntest du überall Ports freigeben.
Natürlich könntest du dir damit ein kleines Sicherheitsmuseum aus schlechten Entscheidungen bauen.
Oder du nutzt einen Reverse Proxy.
Dann läuft nach außen im Idealfall nur:
Port 80 -> HTTP
Port 443 -> HTTPS
Der Reverse Proxy schaut dann auf die Domain:
vault.example.de -> Passwortmanager
photos.example.de -> Fotoverwaltung
home.example.de -> Home Assistant
Der Nutzer sieht nur schöne URLs.
Intern passiert die Weiterleitung.
Das ist elegant.
Also bis es nicht funktioniert.
Dann ist es DNS, TLS, Docker, Firewall, Header, WebSocket, Pfad, Cache oder dein eigener Denkfehler.
Meistens alles gleichzeitig.
2. Forward Proxy vs. Reverse Proxy
Der Begriff Proxy ist leider so ein Wort, das Menschen benutzen, als wüssten alle sofort, was gemeint ist.
Tun sie nicht.
Ein Forward Proxy sitzt aus Sicht des Nutzers vor dem Internet.
Der Client fragt den Proxy, und der Proxy fragt dann das Internet.
Das kennt man aus Firmennetzen, Schulen, Filterlösungen oder alten Zeiten, in denen „Proxy eintragen“ noch ein normales Stück Computerschmerz war.
Ein Forward Proxy schützt oder kontrolliert also eher die Clients.
Ein Reverse Proxy sitzt dagegen vor den Servern.
Der Nutzer fragt den Reverse Proxy, und der Reverse Proxy leitet intern an den passenden Server weiter.
Kurz:
Forward Proxy: Client -> Proxy -> Internet
Reverse Proxy: Internet -> Proxy -> Server
Der Reverse Proxy ist also nicht der Reiseleiter für deinen Browser.
Er ist der Empfangstresen für deine Dienste.
Oder, weniger freundlich:
Er ist der Typ an der Tür, der wissen will, ob du zu vault.example.de oder zu photos.example.de willst, bevor er dich in den richtigen Keller schickt.
3. Warum man das im Homelab will
Ein Reverse Proxy bringt Ordnung.
Und Ordnung ist im Homelab selten, aber schön.
Die Vorteile:
- saubere Subdomains
- zentrale HTTPS-Zertifikate
- weniger Portfreigaben
- einheitliche Zugriffspunkte
- Weiterleitung an verschiedene interne Dienste
- Möglichkeit für Authentifizierung, IP-Filter oder zusätzliche Schutzmechanismen
Vor allem aber: Man muss sich keine Ports merken.
Denn Ports sind diese kleinen Zahlen, die am Anfang noch logisch wirken und später aussehen wie die Seriennummern eines schlechten Traums.
:8080
:8081
:3000
:5000
:9000
:9443
:8123
Irgendwann weiß niemand mehr, was wo läuft.
Dann gibt es ein Wiki.
Dann ist das Wiki veraltet.
Dann sucht man in Docker Compose.
Dann findet man drei alte Container.
Dann startet man versehentlich den falschen neu.
Dann fragt jemand im Haushalt, warum die Fotos weg sind.
Dann möchte man in den Wald ziehen.
Mit Reverse Proxy wird daraus:
https://photos.example.de
Das kann sich sogar ein Mensch merken.
Fast verdächtig.
4. Domains, Subdomains und DNS
Damit ein Reverse Proxy von außen funktioniert, braucht man Domains.
Oder zumindest lokale Namen.
Für öffentlich erreichbare Dienste sieht das oft so aus:
vault.example.de
photos.example.de
home.example.de
Im DNS müssen diese Namen auf deine öffentliche IP-Adresse zeigen.
Zum Beispiel mit A- oder AAAA-Records:
vault.example.de A 203.0.113.42
photos.example.de A 203.0.113.42
home.example.de A 203.0.113.42
Alle zeigen auf dieselbe IP.
Das ist okay.
Der Reverse Proxy unterscheidet später anhand des Hostnamens, welcher Dienst gemeint ist.
Wenn du keine feste öffentliche IP hast, brauchst du DynDNS.
Also einen Dienst, der deine wechselnde IP-Adresse regelmäßig aktualisiert.
Weil Internetanbieter offenbar beschlossen haben, dass Privatanschlüsse ruhig ein kleines Überraschungsei bei der Erreichbarkeit brauchen.
Im Heimnetz kann man auch Split-DNS nutzen.
Dann zeigt photos.example.de intern direkt auf die lokale Adresse des Reverse Proxys, extern aber auf die öffentliche IP.
Das ist sauber.
Aber auch eine sehr gute Gelegenheit, sich selbst zu verwirren.
Denn wenn es intern geht und extern nicht, oder extern geht und intern nicht, beginnt wieder dieser kleine Tanz aus DNS-Cache, NAT, Firewall und Selbstzweifel.
Man kennt es.
5. TLS-Zertifikate und HTTPS
HTTPS ist Pflicht.
Nicht Luxus.
Nicht „machen wir später“.
Nicht „ist ja nur intern“.
HTTPS sorgt dafür, dass die Verbindung verschlüsselt ist und der Browser prüfen kann, ob er mit dem richtigen Server spricht.
Ohne HTTPS schickt man Daten durchs Netz wie Postkarten.
Kann man machen.
Sollte man aber nicht.
Der Reverse Proxy kann TLS zentral übernehmen.
Das nennt man TLS-Termination.
Der Client spricht verschlüsselt mit dem Reverse Proxy.
Der Reverse Proxy leitet intern an den Dienst weiter.
Je nach Setup kann die interne Weiterleitung wieder HTTP oder HTTPS sein.
Für viele Homelab-Setups ist HTTP intern okay, sofern das Netz sauber kontrolliert ist.
Für strengere Umgebungen verschlüsselt man intern ebenfalls.
Der große Vorteil: Du musst Zertifikate nicht für jeden Dienst einzeln pflegen.
Der Reverse Proxy kümmert sich darum.
Mit Let’s Encrypt können Zertifikate automatisch ausgestellt und erneuert werden.
Das ist großartig.
Weil abgelaufene Zertifikate zu den dümmsten Arten gehören, sich selbst auszusperren.
Nichts sagt „professionelle Infrastruktur“ wie eine rote Browserwarnung, weil jemand ein Datum vergessen hat.
6. Ports und die kleine Hölle der Freigaben
Viele Homelab-Katastrophen beginnen mit dem Satz:
Ich mache den Port mal kurz auf.
Kurz.
Natürlich.
Dann ist Port 8080 offen.
Dann Port 8123.
Dann 3000.
Dann 9000.
Dann findet man Monate später eine Portfreigabe, bei der niemand mehr weiß, wozu sie gehört.
Vielleicht wichtig.
Vielleicht gefährlich.
Vielleicht beides.
Ein Reverse Proxy reduziert das.
Du leitest normalerweise nur Port 80 und 443 auf den Reverse Proxy weiter.
Internet -> Router Port 80/443 -> Reverse Proxy -> interner Dienst
Die Dienste selbst müssen nicht direkt aus dem Internet erreichbar sein.
Das ist gut.
Denn nicht jeder Dienst ist dafür gebaut, direkt im Internet zu stehen.
Viele Tools sind eher so:
Ich bin für dein LAN gedacht. Bitte stelle mich nicht nackt ins Netz.
Und dann macht es trotzdem jemand.
Mit Standardpasswort.
Und wundert sich.
Ein Reverse Proxy ist kein magischer Schutzschild.
Aber er hilft, Angriffsfläche zu reduzieren und Zugriffe zentraler zu kontrollieren.
Das ist besser als Portfreigaben-Wildwuchs.
Portfreigaben-Wildwuchs ist wie Kabelsalat.
Nur mit mehr Sicherheitslücken.
7. Caddy: Der bequeme Weg
Caddy ist ein moderner Webserver und Reverse Proxy.
Sein großer Charme: HTTPS ist eingebaut und sehr angenehm automatisiert.
Eine einfache Caddy-Konfiguration sieht so aus:
photos.example.de {
reverse_proxy 192.168.178.42:2283
}
vault.example.de {
reverse_proxy 192.168.178.43:8080
}
Das war es oft schon.
Caddy kümmert sich um Zertifikate.
Caddy erneuert sie.
Caddy macht erstaunlich viel richtig, ohne dass man direkt 80 Zeilen Konfiguration schreiben muss.
Das ist angenehm.
Fast verdächtig angenehm.
Für Docker sieht ein einfaches Setup so aus:
services:
caddy:
image: caddy:latest
container_name: caddy
restart: unless-stopped
ports:
- "80:80"
- "443:443"
volumes:
- ./Caddyfile:/etc/caddy/Caddyfile:ro
- caddy_data:/data
- caddy_config:/config
volumes:
caddy_data:
caddy_config:
Wichtig ist das Volume caddy_data.
Dort liegen Zertifikate und andere Daten.
Wenn du das einfach wegwirfst, darf Caddy neu anfangen.
Und Let’s Encrypt findet es nicht lustig, wenn du zu oft neu anfängst.
Rate Limits sind der kleine Türsteher des Zertifikatswesens.
Auch die haben irgendwann keinen Bock mehr auf deinen Bastelabend.
8. Nginx: Der Klassiker mit Kanten
Nginx ist der Klassiker.
Robust.
Schnell.
Überall im Einsatz.
Und manchmal konfiguriert wie ein alter Heizkeller.
Eine einfache Nginx-Reverse-Proxy-Konfiguration:
server {
listen 80;
server_name photos.example.de;
location / {
proxy_pass http://192.168.178.42:2283;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
}
Das leitet photos.example.de an den internen Dienst weiter.
Für HTTPS braucht man Zertifikate.
Zum Beispiel mit Certbot.
Das funktioniert.
Aber man muss mehr selbst bauen als bei Caddy.
Nginx ist mächtig.
Mächtig ist in der IT oft ein anderes Wort für:
Du kannst sehr viel richtig machen und sehr viel falsch.
Nginx lohnt sich, wenn man genau kontrollieren will, was passiert.
Header.
Caching.
Load Balancing.
Timeouts.
Buffering.
WebSockets.
Spezialfälle.
Also all die Dinge, die man anfangs nicht braucht, bis man sie plötzlich dringend braucht und sich fragt, warum der Dienst hinter dem Proxy zwar lädt, aber keine Live-Aktualisierung mehr funktioniert.
Spoiler:
Oft WebSockets.
Es sind erstaunlich oft WebSockets.
9. Docker-Compose-Beispiel
Nehmen wir ein kleines Beispiel mit Caddy und einem internen Webdienst.
Wir bauen einen Demo-Dienst mit Nginx und lassen Caddy davor stehen.
services:
caddy:
image: caddy:latest
container_name: caddy
restart: unless-stopped
ports:
- "80:80"
- "443:443"
volumes:
- ./Caddyfile:/etc/caddy/Caddyfile:ro
- caddy_data:/data
- caddy_config:/config
networks:
- proxy
demo:
image: nginx:alpine
container_name: demo-web
restart: unless-stopped
networks:
- proxy
networks:
proxy:
volumes:
caddy_data:
caddy_config:
Die Caddyfile:
demo.example.de {
reverse_proxy demo:80
}
Der wichtige Punkt: Caddy und der Dienst sind im selben Docker-Netzwerk.
Dadurch kann Caddy den Container über den Namen demo erreichen.
Nicht über localhost.
Das ist ein Klassiker.
Viele schreiben im Container:
localhost:3000
Und wundern sich.
Aber localhost bedeutet innerhalb des Caddy-Containers: der Caddy-Container selbst.
Nicht dein Host.
Nicht der andere Container.
Nicht „das da irgendwo“.
Localhost ist immer lokal.
Klingt banal.
Hat trotzdem schon sehr viele Abende gefressen.
Wenn du einen Dienst auf dem Host erreichen willst, brauchst du je nach Umgebung andere Wege, zum Beispiel die Host-IP oder spezielle Docker-Namen wie host.docker.internal, falls verfügbar.
Aber sauberer ist oft: Dienste gemeinsam in ein Docker-Netzwerk packen und über Containernamen ansprechen.
Weniger Magie.
Mehr Ordnung.
Also zumindest theoretisch.
10. Typische Fehler
Reverse Proxies sind wunderbar.
Bis sie es nicht sind.
Hier ein paar Klassiker.
DNS zeigt auf die falsche IP
Du hast alles richtig konfiguriert.
Caddy läuft.
Container laufen.
Ports sind offen.
Und trotzdem kommt nichts an.
Dann zeigt die Domain noch auf die alte IP.
Oder auf gar keine.
Oder auf IPv6, obwohl dein IPv6-Setup aussieht wie ein Unfallbericht.
DNS ist immer eine Prüfung wert.
dig photos.example.de
Oder gezielt:
dig @1.1.1.1 photos.example.de
Wenn DNS falsch ist, kann der Reverse Proxy auch nichts dafür.
Er steht dann korrekt an der Tür.
Nur alle Gäste fahren zum falschen Haus.
Port 80 oder 443 nicht erreichbar
Für Let’s Encrypt braucht Caddy oder ein anderer Client oft Port 80 oder 443.
Wenn dein Router nicht richtig weiterleitet, dein Provider blockt oder du hinter CGNAT sitzt, wird es lustig.
CGNAT ist besonders schön.
Da hast du keine eigene öffentliche IPv4-Adresse.
Du kannst Ports weiterleiten, bis du alt wirst.
Von außen kommt trotzdem nichts an.
Dann brauchst du Alternativen:
- IPv6 sauber nutzen
- Tunnel verwenden
- VPS als Einstiegspunkt
- VPN
- Cloudflare Tunnel oder ähnliche Dienste
- Anbieter mit echter öffentlicher IP
CGNAT ist wie eine Haustür, die du innen wunderbar streichen kannst, die aber in einem fremden Flur steht.
Falsche Weiterleitung intern
Der Reverse Proxy erreicht den Dienst nicht.
Falsche IP.
Falscher Port.
Falscher Containername.
Falsches Netzwerk.
Dienst hört nur auf 127.0.0.1.
Firewall blockt.
Alles möglich.
Testen:
docker exec -it caddy sh
wget -O- http://demo:80
Oder mit curl, falls vorhanden.
Man prüft also aus dem Proxy-Container heraus, ob der Ziel-Dienst erreichbar ist.
Nicht von deinem Laptop.
Nicht aus Gefühl.
Direkt aus der Perspektive des Proxys.
Denn Netzwerke sind Perspektivensache.
Wie Politik.
Nur mit mehr Ports.
WebSockets kaputt
Manche Dienste brauchen WebSockets.
Wenn die Verbindung nicht korrekt weitergeleitet wird, lädt die Seite vielleicht, aber Live-Daten, Konsolen, Logs oder Benachrichtigungen funktionieren nicht.
Caddy macht vieles automatisch richtig.
Bei Nginx muss man manchmal nachhelfen:
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
Wenn eine App halb funktioniert, ist das oft schlimmer als gar nicht.
Gar nicht ist wenigstens ehrlich.
Halb kaputt ist Debugging mit Gaslighting.
Mixed Content
Die Seite läuft über HTTPS, lädt aber interne Ressourcen über HTTP.
Der Browser blockt.
Die Seite sieht aus wie ein Möbelstück ohne Schrauben.
Dann muss der Dienst wissen, dass er hinter HTTPS läuft.
Dafür sind Header wie diese wichtig:
X-Forwarded-Proto: https
X-Forwarded-Host: example.de
Viele Anwendungen haben außerdem Einstellungen wie:
TRUSTED_PROXIES
PUBLIC_URL
BASE_URL
ROOT_URL
Oder andere Namen, weil Konsistenz im Softwarebereich offenbar als Schwäche gilt.
Uploads brechen ab
Große Uploads scheitern.
Fotos, Backups, Dateien.
Dann sind oft Limits im Proxy schuld.
Bei Nginx zum Beispiel:
client_max_body_size 100M;
Ohne Anpassung blockt Nginx größere Requests.
Caddy ist da oft entspannter, aber auch dort können Timeouts oder Upstream-Limits relevant werden.
Wenn ein Dienst kleine Dateien annimmt, große aber nicht, liegt es selten an kosmischer Ungerechtigkeit.
Meistens ist es irgendein Limit.
Kosmische Ungerechtigkeit kommt dann später, wenn du es gefunden hast und der nächste Fehler wartet.
11. Sicherheit: Nur weil es geht, muss es nicht ins Internet
Das wichtigste Kapitel.
Nur weil du einen Dienst schön über https://irgendwas.example.de erreichbar machen kannst, heißt das nicht, dass du es tun solltest.
Nicht jeder Dienst gehört ins öffentliche Internet.
Punkt.
Ein Reverse Proxy macht Dinge bequemer.
Er macht sie nicht automatisch sicher.
Wenn ein Dienst eine schwache Authentifizierung hat, bleibt sie schwach.
Wenn ein Dienst Sicherheitslücken hat, bleiben sie Sicherheitslücken.
Wenn du Admin-Oberflächen offen ins Internet stellst, nur weil es hübsch aussieht, hast du keine Infrastruktur gebaut.
Du hast eine Einladung geschrieben.
An Bots.
Und Bots haben Zeit.
Sehr viel Zeit.
Ein paar Grundregeln:
- Nur veröffentlichen, was wirklich öffentlich erreichbar sein muss.
- Starke Authentifizierung nutzen.
- 2FA aktivieren, wo möglich.
- Dienste aktuell halten.
- Admin-Oberflächen nicht unnötig ins Internet stellen.
- IP-Filter nutzen, wenn sinnvoll.
- Zusätzliche Authentifizierung vor sensible Dienste setzen.
- Logs anschauen.
- Backups machen.
Besonders hilfreich: VPN.
Viele Dienste müssen gar nicht öffentlich sein.
Man kann sie nur über WireGuard, Tailscale, ZeroTier oder ein klassisches VPN erreichbar machen.
Dann bleibt die Angriffsfläche kleiner.
Ja, öffentliche URLs sind bequem.
Aber Bequemlichkeit ist in der IT oft der kleine Bruder von „Warum wurde mein Server für Kryptomining benutzt?“.
Ein Reverse Proxy ist ein Werkzeug.
Kein Schutzengel.
Und schon gar keiner mit automatischem Patchmanagement.
12. Fazit
Ein Reverse Proxy ist eines dieser Dinge, die ein Homelab plötzlich erwachsen wirken lassen.
Aus 192.168.178.42:8080 wird https://vault.example.de.
Aus Port-Chaos wird Struktur.
Aus Zertifikatsgefrickel wird zentrale Verwaltung.
Aus „Wo läuft das nochmal?“ wird wenigstens eine Chance auf Ordnung.
Das ist gut.
Sehr gut sogar.
Aber ein Reverse Proxy bringt auch Verantwortung.
DNS muss stimmen.
Ports müssen stimmen.
Zertifikate müssen stimmen.
Header müssen stimmen.
Dienste müssen wissen, dass sie hinter einem Proxy laufen.
Und vor allem muss man entscheiden, was wirklich von außen erreichbar sein soll.
Denn das Internet ist kein freundlicher Ort.
Es ist eher wie ein Bahnhofsklo mit Glasfaseranschluss.
Alles, was offen ist, wird gefunden.
Alles, was gefunden wird, wird ausprobiert.
Alles, was schlecht konfiguriert ist, wird irgendwann dein Problem.
Ein Reverse Proxy hilft, den Eingang zu ordnen.
Aber du musst immer noch entscheiden, wen du reinlässt.
Oder anders gesagt:
Der Reverse Proxy ist der Türsteher.
Aber wenn du die Tür zu allem aufmachst, kann auch der beste Türsteher nur noch müde gucken.