{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreiccc3ddxowq3cuc2e4eblxgefx2tlf5nqvuxdkefpvrspzajixwwm",
    "uri": "at://did:plc:4hfnzpcvsy5k3uwjqhaynx45/app.bsky.feed.post/3mnovvmi3cbj2"
  },
  "description": "Ein Reverse Proxy ist dieser unsichtbare Türsteher im Heimnetz, der entscheidet, welcher Dienst unter welcher Domain erreichbar ist. Klingt trocken. Ist aber der Unterschied zwischen schönem Homelab und Portfreigaben wie aus der Hölle.",
  "path": "/reverse-proxy-der-tursteher-furs-homelab-der-meistens-schuld-ist-wenn-gar-nichts-geht/",
  "publishedAt": "2026-06-07T10:00:17.000Z",
  "site": "https://codeundkram.de",
  "tags": [
    "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.1.1.1"
  ],
  "textContent": "Irgendwann passiert es.\n\nMan hat ein Homelab.\n\nErst nur ein NAS.\n\nDann ein kleiner Mini-PC.\n\nDann Docker.\n\nDann ein paar Dienste.\n\nDann noch ein Dashboard.\n\nDann ein Passwortmanager.\n\nDann ein Git-Server.\n\nDann eine Fotoverwaltung.\n\nDann 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.\n\nUnd plötzlich steht man da mit URLs wie:\n\n\n    http://192.168.178.42:8080\n    http://192.168.178.42:3000\n    http://192.168.178.42:9000\n    http://192.168.178.43:8123\n\n\nSehr schön.\n\nSehr professionell.\n\nSehr „Ich habe die Kontrolle verloren, aber immerhin läuft es“.\n\nDann kommt der Moment, in dem man sich denkt:\n\n> Das müsste doch auch hübscher gehen.\n\nAlso zum Beispiel:\n\n\n    https://vault.example.de\n    https://photos.example.de\n    https://home.example.de\n    https://git.example.de\n\n\nUnd genau da kommt der Reverse Proxy ins Spiel.\n\nDer Reverse Proxy ist der Türsteher deines Homelabs.\n\nEr steht vorne an der Tür, nimmt Anfragen entgegen, schaut auf den Namen, entscheidet, welcher Dienst gemeint ist, und leitet die Anfrage weiter.\n\nWenn er gut konfiguriert ist, merkt niemand etwas.\n\nWenn er schlecht konfiguriert ist, sitzt du nachts um 00:37 Uhr vor Logs, die so hilfreich sind wie ein Drucker mit Bindungsangst.\n\n## Inhaltsverzeichnis\n\n  1. Was ist ein Reverse Proxy?\n  2. Forward Proxy vs. Reverse Proxy\n  3. Warum man das im Homelab will\n  4. Domains, Subdomains und DNS\n  5. TLS-Zertifikate und HTTPS\n  6. Ports und die kleine Hölle der Freigaben\n  7. Caddy: Der bequeme Weg\n  8. Nginx: Der Klassiker mit Kanten\n  9. Docker-Compose-Beispiel\n  10. Typische Fehler\n  11. Sicherheit: Nur weil es geht, muss es nicht ins Internet\n  12. Fazit\n\n\n\n* * *\n\n## 1. Was ist ein Reverse Proxy?\n\nEin Reverse Proxy ist ein Server, der Anfragen von außen entgegennimmt und intern an den richtigen Dienst weiterleitet.\n\nStell dir vor, du hast mehrere Dienste im Heimnetz:\n\n  * Passwortmanager auf Port 8080\n  * Fotoverwaltung auf Port 2283\n  * Dashboard auf Port 3000\n  * Home Assistant auf Port 8123\n\n\n\nNatürlich könntest du jeden Dienst direkt erreichbar machen.\n\nNatürlich könntest du überall Ports freigeben.\n\nNatürlich könntest du dir damit ein kleines Sicherheitsmuseum aus schlechten Entscheidungen bauen.\n\nOder du nutzt einen Reverse Proxy.\n\nDann läuft nach außen im Idealfall nur:\n\n\n    Port 80  -> HTTP\n    Port 443 -> HTTPS\n\n\nDer Reverse Proxy schaut dann auf die Domain:\n\n\n    vault.example.de  -> Passwortmanager\n    photos.example.de -> Fotoverwaltung\n    home.example.de   -> Home Assistant\n\n\nDer Nutzer sieht nur schöne URLs.\n\nIntern passiert die Weiterleitung.\n\nDas ist elegant.\n\nAlso bis es nicht funktioniert.\n\nDann ist es DNS, TLS, Docker, Firewall, Header, WebSocket, Pfad, Cache oder dein eigener Denkfehler.\n\nMeistens alles gleichzeitig.\n\n* * *\n\n## 2. Forward Proxy vs. Reverse Proxy\n\nDer Begriff Proxy ist leider so ein Wort, das Menschen benutzen, als wüssten alle sofort, was gemeint ist.\n\nTun sie nicht.\n\nEin **Forward Proxy** sitzt aus Sicht des Nutzers vor dem Internet.\n\nDer Client fragt den Proxy, und der Proxy fragt dann das Internet.\n\nDas kennt man aus Firmennetzen, Schulen, Filterlösungen oder alten Zeiten, in denen „Proxy eintragen“ noch ein normales Stück Computerschmerz war.\n\nEin Forward Proxy schützt oder kontrolliert also eher die Clients.\n\nEin **Reverse Proxy** sitzt dagegen vor den Servern.\n\nDer Nutzer fragt den Reverse Proxy, und der Reverse Proxy leitet intern an den passenden Server weiter.\n\nKurz:\n\n\n    Forward Proxy: Client -> Proxy -> Internet\n    Reverse Proxy: Internet -> Proxy -> Server\n\n\nDer Reverse Proxy ist also nicht der Reiseleiter für deinen Browser.\n\nEr ist der Empfangstresen für deine Dienste.\n\nOder, weniger freundlich:\n\nEr 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.\n\n* * *\n\n## 3. Warum man das im Homelab will\n\nEin Reverse Proxy bringt Ordnung.\n\nUnd Ordnung ist im Homelab selten, aber schön.\n\nDie Vorteile:\n\n  * saubere Subdomains\n  * zentrale HTTPS-Zertifikate\n  * weniger Portfreigaben\n  * einheitliche Zugriffspunkte\n  * Weiterleitung an verschiedene interne Dienste\n  * Möglichkeit für Authentifizierung, IP-Filter oder zusätzliche Schutzmechanismen\n\n\n\nVor allem aber: Man muss sich keine Ports merken.\n\nDenn Ports sind diese kleinen Zahlen, die am Anfang noch logisch wirken und später aussehen wie die Seriennummern eines schlechten Traums.\n\n\n    :8080\n    :8081\n    :3000\n    :5000\n    :9000\n    :9443\n    :8123\n\n\nIrgendwann weiß niemand mehr, was wo läuft.\n\nDann gibt es ein Wiki.\n\nDann ist das Wiki veraltet.\n\nDann sucht man in Docker Compose.\n\nDann findet man drei alte Container.\n\nDann startet man versehentlich den falschen neu.\n\nDann fragt jemand im Haushalt, warum die Fotos weg sind.\n\nDann möchte man in den Wald ziehen.\n\nMit Reverse Proxy wird daraus:\n\n\n    https://photos.example.de\n\n\nDas kann sich sogar ein Mensch merken.\n\nFast verdächtig.\n\n* * *\n\n## 4. Domains, Subdomains und DNS\n\nDamit ein Reverse Proxy von außen funktioniert, braucht man Domains.\n\nOder zumindest lokale Namen.\n\nFür öffentlich erreichbare Dienste sieht das oft so aus:\n\n\n    vault.example.de\n    photos.example.de\n    home.example.de\n\n\nIm DNS müssen diese Namen auf deine öffentliche IP-Adresse zeigen.\n\nZum Beispiel mit A- oder AAAA-Records:\n\n\n    vault.example.de  A     203.0.113.42\n    photos.example.de A     203.0.113.42\n    home.example.de   A     203.0.113.42\n\n\nAlle zeigen auf dieselbe IP.\n\nDas ist okay.\n\nDer Reverse Proxy unterscheidet später anhand des Hostnamens, welcher Dienst gemeint ist.\n\nWenn du keine feste öffentliche IP hast, brauchst du DynDNS.\n\nAlso einen Dienst, der deine wechselnde IP-Adresse regelmäßig aktualisiert.\n\nWeil Internetanbieter offenbar beschlossen haben, dass Privatanschlüsse ruhig ein kleines Überraschungsei bei der Erreichbarkeit brauchen.\n\nIm Heimnetz kann man auch Split-DNS nutzen.\n\nDann zeigt `photos.example.de` intern direkt auf die lokale Adresse des Reverse Proxys, extern aber auf die öffentliche IP.\n\nDas ist sauber.\n\nAber auch eine sehr gute Gelegenheit, sich selbst zu verwirren.\n\nDenn 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.\n\nMan kennt es.\n\n* * *\n\n## 5. TLS-Zertifikate und HTTPS\n\nHTTPS ist Pflicht.\n\nNicht Luxus.\n\nNicht „machen wir später“.\n\nNicht „ist ja nur intern“.\n\nHTTPS sorgt dafür, dass die Verbindung verschlüsselt ist und der Browser prüfen kann, ob er mit dem richtigen Server spricht.\n\nOhne HTTPS schickt man Daten durchs Netz wie Postkarten.\n\nKann man machen.\n\nSollte man aber nicht.\n\nDer Reverse Proxy kann TLS zentral übernehmen.\n\nDas nennt man TLS-Termination.\n\nDer Client spricht verschlüsselt mit dem Reverse Proxy.\n\nDer Reverse Proxy leitet intern an den Dienst weiter.\n\nJe nach Setup kann die interne Weiterleitung wieder HTTP oder HTTPS sein.\n\nFür viele Homelab-Setups ist HTTP intern okay, sofern das Netz sauber kontrolliert ist.\n\nFür strengere Umgebungen verschlüsselt man intern ebenfalls.\n\nDer große Vorteil: Du musst Zertifikate nicht für jeden Dienst einzeln pflegen.\n\nDer Reverse Proxy kümmert sich darum.\n\nMit Let’s Encrypt können Zertifikate automatisch ausgestellt und erneuert werden.\n\nDas ist großartig.\n\nWeil abgelaufene Zertifikate zu den dümmsten Arten gehören, sich selbst auszusperren.\n\nNichts sagt „professionelle Infrastruktur“ wie eine rote Browserwarnung, weil jemand ein Datum vergessen hat.\n\n* * *\n\n## 6. Ports und die kleine Hölle der Freigaben\n\nViele Homelab-Katastrophen beginnen mit dem Satz:\n\n> Ich mache den Port mal kurz auf.\n\nKurz.\n\nNatürlich.\n\nDann ist Port 8080 offen.\n\nDann Port 8123.\n\nDann 3000.\n\nDann 9000.\n\nDann findet man Monate später eine Portfreigabe, bei der niemand mehr weiß, wozu sie gehört.\n\nVielleicht wichtig.\n\nVielleicht gefährlich.\n\nVielleicht beides.\n\nEin Reverse Proxy reduziert das.\n\nDu leitest normalerweise nur Port 80 und 443 auf den Reverse Proxy weiter.\n\n\n    Internet -> Router Port 80/443 -> Reverse Proxy -> interner Dienst\n\n\nDie Dienste selbst müssen nicht direkt aus dem Internet erreichbar sein.\n\nDas ist gut.\n\nDenn nicht jeder Dienst ist dafür gebaut, direkt im Internet zu stehen.\n\nViele Tools sind eher so:\n\n> Ich bin für dein LAN gedacht. Bitte stelle mich nicht nackt ins Netz.\n\nUnd dann macht es trotzdem jemand.\n\nMit Standardpasswort.\n\nUnd wundert sich.\n\nEin Reverse Proxy ist kein magischer Schutzschild.\n\nAber er hilft, Angriffsfläche zu reduzieren und Zugriffe zentraler zu kontrollieren.\n\nDas ist besser als Portfreigaben-Wildwuchs.\n\nPortfreigaben-Wildwuchs ist wie Kabelsalat.\n\nNur mit mehr Sicherheitslücken.\n\n* * *\n\n## 7. Caddy: Der bequeme Weg\n\nCaddy ist ein moderner Webserver und Reverse Proxy.\n\nSein großer Charme: HTTPS ist eingebaut und sehr angenehm automatisiert.\n\nEine einfache Caddy-Konfiguration sieht so aus:\n\n\n    photos.example.de {\n        reverse_proxy 192.168.178.42:2283\n    }\n\n    vault.example.de {\n        reverse_proxy 192.168.178.43:8080\n    }\n\n\nDas war es oft schon.\n\nCaddy kümmert sich um Zertifikate.\n\nCaddy erneuert sie.\n\nCaddy macht erstaunlich viel richtig, ohne dass man direkt 80 Zeilen Konfiguration schreiben muss.\n\nDas ist angenehm.\n\nFast verdächtig angenehm.\n\nFür Docker sieht ein einfaches Setup so aus:\n\n\n    services:\n      caddy:\n        image: caddy:latest\n        container_name: caddy\n        restart: unless-stopped\n        ports:\n          - \"80:80\"\n          - \"443:443\"\n        volumes:\n          - ./Caddyfile:/etc/caddy/Caddyfile:ro\n          - caddy_data:/data\n          - caddy_config:/config\n\n    volumes:\n      caddy_data:\n      caddy_config:\n\n\nWichtig ist das Volume `caddy_data`.\n\nDort liegen Zertifikate und andere Daten.\n\nWenn du das einfach wegwirfst, darf Caddy neu anfangen.\n\nUnd Let’s Encrypt findet es nicht lustig, wenn du zu oft neu anfängst.\n\nRate Limits sind der kleine Türsteher des Zertifikatswesens.\n\nAuch die haben irgendwann keinen Bock mehr auf deinen Bastelabend.\n\n* * *\n\n## 8. Nginx: Der Klassiker mit Kanten\n\nNginx ist der Klassiker.\n\nRobust.\n\nSchnell.\n\nÜberall im Einsatz.\n\nUnd manchmal konfiguriert wie ein alter Heizkeller.\n\nEine einfache Nginx-Reverse-Proxy-Konfiguration:\n\n\n    server {\n        listen 80;\n        server_name photos.example.de;\n\n        location / {\n            proxy_pass http://192.168.178.42:2283;\n            proxy_set_header Host $host;\n            proxy_set_header X-Real-IP $remote_addr;\n            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;\n            proxy_set_header X-Forwarded-Proto $scheme;\n        }\n    }\n\n\nDas leitet `photos.example.de` an den internen Dienst weiter.\n\nFür HTTPS braucht man Zertifikate.\n\nZum Beispiel mit Certbot.\n\nDas funktioniert.\n\nAber man muss mehr selbst bauen als bei Caddy.\n\nNginx ist mächtig.\n\nMächtig ist in der IT oft ein anderes Wort für:\n\n> Du kannst sehr viel richtig machen und sehr viel falsch.\n\nNginx lohnt sich, wenn man genau kontrollieren will, was passiert.\n\nHeader.\n\nCaching.\n\nLoad Balancing.\n\nTimeouts.\n\nBuffering.\n\nWebSockets.\n\nSpezialfälle.\n\nAlso 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.\n\nSpoiler:\n\nOft WebSockets.\n\nEs sind erstaunlich oft WebSockets.\n\n* * *\n\n## 9. Docker-Compose-Beispiel\n\nNehmen wir ein kleines Beispiel mit Caddy und einem internen Webdienst.\n\nWir bauen einen Demo-Dienst mit Nginx und lassen Caddy davor stehen.\n\n\n    services:\n      caddy:\n        image: caddy:latest\n        container_name: caddy\n        restart: unless-stopped\n        ports:\n          - \"80:80\"\n          - \"443:443\"\n        volumes:\n          - ./Caddyfile:/etc/caddy/Caddyfile:ro\n          - caddy_data:/data\n          - caddy_config:/config\n        networks:\n          - proxy\n\n      demo:\n        image: nginx:alpine\n        container_name: demo-web\n        restart: unless-stopped\n        networks:\n          - proxy\n\n    networks:\n      proxy:\n\n    volumes:\n      caddy_data:\n      caddy_config:\n\n\nDie `Caddyfile`:\n\n\n    demo.example.de {\n        reverse_proxy demo:80\n    }\n\n\nDer wichtige Punkt: Caddy und der Dienst sind im selben Docker-Netzwerk.\n\nDadurch kann Caddy den Container über den Namen `demo` erreichen.\n\nNicht über `localhost`.\n\nDas ist ein Klassiker.\n\nViele schreiben im Container:\n\n\n    localhost:3000\n\n\nUnd wundern sich.\n\nAber `localhost` bedeutet innerhalb des Caddy-Containers: der Caddy-Container selbst.\n\nNicht dein Host.\n\nNicht der andere Container.\n\nNicht „das da irgendwo“.\n\nLocalhost ist immer lokal.\n\nKlingt banal.\n\nHat trotzdem schon sehr viele Abende gefressen.\n\nWenn 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.\n\nAber sauberer ist oft: Dienste gemeinsam in ein Docker-Netzwerk packen und über Containernamen ansprechen.\n\nWeniger Magie.\n\nMehr Ordnung.\n\nAlso zumindest theoretisch.\n\n* * *\n\n## 10. Typische Fehler\n\nReverse Proxies sind wunderbar.\n\nBis sie es nicht sind.\n\nHier ein paar Klassiker.\n\n### DNS zeigt auf die falsche IP\n\nDu hast alles richtig konfiguriert.\n\nCaddy läuft.\n\nContainer laufen.\n\nPorts sind offen.\n\nUnd trotzdem kommt nichts an.\n\nDann zeigt die Domain noch auf die alte IP.\n\nOder auf gar keine.\n\nOder auf IPv6, obwohl dein IPv6-Setup aussieht wie ein Unfallbericht.\n\nDNS ist immer eine Prüfung wert.\n\n\n    dig photos.example.de\n\n\nOder gezielt:\n\n\n    dig @1.1.1.1 photos.example.de\n\n\nWenn DNS falsch ist, kann der Reverse Proxy auch nichts dafür.\n\nEr steht dann korrekt an der Tür.\n\nNur alle Gäste fahren zum falschen Haus.\n\n### Port 80 oder 443 nicht erreichbar\n\nFür Let’s Encrypt braucht Caddy oder ein anderer Client oft Port 80 oder 443.\n\nWenn dein Router nicht richtig weiterleitet, dein Provider blockt oder du hinter CGNAT sitzt, wird es lustig.\n\nCGNAT ist besonders schön.\n\nDa hast du keine eigene öffentliche IPv4-Adresse.\n\nDu kannst Ports weiterleiten, bis du alt wirst.\n\nVon außen kommt trotzdem nichts an.\n\nDann brauchst du Alternativen:\n\n  * IPv6 sauber nutzen\n  * Tunnel verwenden\n  * VPS als Einstiegspunkt\n  * VPN\n  * Cloudflare Tunnel oder ähnliche Dienste\n  * Anbieter mit echter öffentlicher IP\n\n\n\nCGNAT ist wie eine Haustür, die du innen wunderbar streichen kannst, die aber in einem fremden Flur steht.\n\n### Falsche Weiterleitung intern\n\nDer Reverse Proxy erreicht den Dienst nicht.\n\nFalsche IP.\n\nFalscher Port.\n\nFalscher Containername.\n\nFalsches Netzwerk.\n\nDienst hört nur auf `127.0.0.1`.\n\nFirewall blockt.\n\nAlles möglich.\n\nTesten:\n\n\n    docker exec -it caddy sh\n    wget -O- http://demo:80\n\n\nOder mit `curl`, falls vorhanden.\n\nMan prüft also aus dem Proxy-Container heraus, ob der Ziel-Dienst erreichbar ist.\n\nNicht von deinem Laptop.\n\nNicht aus Gefühl.\n\nDirekt aus der Perspektive des Proxys.\n\nDenn Netzwerke sind Perspektivensache.\n\nWie Politik.\n\nNur mit mehr Ports.\n\n### WebSockets kaputt\n\nManche Dienste brauchen WebSockets.\n\nWenn die Verbindung nicht korrekt weitergeleitet wird, lädt die Seite vielleicht, aber Live-Daten, Konsolen, Logs oder Benachrichtigungen funktionieren nicht.\n\nCaddy macht vieles automatisch richtig.\n\nBei Nginx muss man manchmal nachhelfen:\n\n\n    proxy_http_version 1.1;\n    proxy_set_header Upgrade $http_upgrade;\n    proxy_set_header Connection \"upgrade\";\n\n\nWenn eine App halb funktioniert, ist das oft schlimmer als gar nicht.\n\nGar nicht ist wenigstens ehrlich.\n\nHalb kaputt ist Debugging mit Gaslighting.\n\n### Mixed Content\n\nDie Seite läuft über HTTPS, lädt aber interne Ressourcen über HTTP.\n\nDer Browser blockt.\n\nDie Seite sieht aus wie ein Möbelstück ohne Schrauben.\n\nDann muss der Dienst wissen, dass er hinter HTTPS läuft.\n\nDafür sind Header wie diese wichtig:\n\n\n    X-Forwarded-Proto: https\n    X-Forwarded-Host: example.de\n\n\nViele Anwendungen haben außerdem Einstellungen wie:\n\n\n    TRUSTED_PROXIES\n    PUBLIC_URL\n    BASE_URL\n    ROOT_URL\n\n\nOder andere Namen, weil Konsistenz im Softwarebereich offenbar als Schwäche gilt.\n\n### Uploads brechen ab\n\nGroße Uploads scheitern.\n\nFotos, Backups, Dateien.\n\nDann sind oft Limits im Proxy schuld.\n\nBei Nginx zum Beispiel:\n\n\n    client_max_body_size 100M;\n\n\nOhne Anpassung blockt Nginx größere Requests.\n\nCaddy ist da oft entspannter, aber auch dort können Timeouts oder Upstream-Limits relevant werden.\n\nWenn ein Dienst kleine Dateien annimmt, große aber nicht, liegt es selten an kosmischer Ungerechtigkeit.\n\nMeistens ist es irgendein Limit.\n\nKosmische Ungerechtigkeit kommt dann später, wenn du es gefunden hast und der nächste Fehler wartet.\n\n* * *\n\n## 11. Sicherheit: Nur weil es geht, muss es nicht ins Internet\n\nDas wichtigste Kapitel.\n\nNur weil du einen Dienst schön über `https://irgendwas.example.de` erreichbar machen kannst, heißt das nicht, dass du es tun solltest.\n\nNicht jeder Dienst gehört ins öffentliche Internet.\n\nPunkt.\n\nEin Reverse Proxy macht Dinge bequemer.\n\nEr macht sie nicht automatisch sicher.\n\nWenn ein Dienst eine schwache Authentifizierung hat, bleibt sie schwach.\n\nWenn ein Dienst Sicherheitslücken hat, bleiben sie Sicherheitslücken.\n\nWenn du Admin-Oberflächen offen ins Internet stellst, nur weil es hübsch aussieht, hast du keine Infrastruktur gebaut.\n\nDu hast eine Einladung geschrieben.\n\nAn Bots.\n\nUnd Bots haben Zeit.\n\nSehr viel Zeit.\n\nEin paar Grundregeln:\n\n  * Nur veröffentlichen, was wirklich öffentlich erreichbar sein muss.\n  * Starke Authentifizierung nutzen.\n  * 2FA aktivieren, wo möglich.\n  * Dienste aktuell halten.\n  * Admin-Oberflächen nicht unnötig ins Internet stellen.\n  * IP-Filter nutzen, wenn sinnvoll.\n  * Zusätzliche Authentifizierung vor sensible Dienste setzen.\n  * Logs anschauen.\n  * Backups machen.\n\n\n\nBesonders hilfreich: VPN.\n\nViele Dienste müssen gar nicht öffentlich sein.\n\nMan kann sie nur über WireGuard, Tailscale, ZeroTier oder ein klassisches VPN erreichbar machen.\n\nDann bleibt die Angriffsfläche kleiner.\n\nJa, öffentliche URLs sind bequem.\n\nAber Bequemlichkeit ist in der IT oft der kleine Bruder von „Warum wurde mein Server für Kryptomining benutzt?“.\n\nEin Reverse Proxy ist ein Werkzeug.\n\nKein Schutzengel.\n\nUnd schon gar keiner mit automatischem Patchmanagement.\n\n* * *\n\n## 12. Fazit\n\nEin Reverse Proxy ist eines dieser Dinge, die ein Homelab plötzlich erwachsen wirken lassen.\n\nAus `192.168.178.42:8080` wird `https://vault.example.de`.\n\nAus Port-Chaos wird Struktur.\n\nAus Zertifikatsgefrickel wird zentrale Verwaltung.\n\nAus „Wo läuft das nochmal?“ wird wenigstens eine Chance auf Ordnung.\n\nDas ist gut.\n\nSehr gut sogar.\n\nAber ein Reverse Proxy bringt auch Verantwortung.\n\nDNS muss stimmen.\n\nPorts müssen stimmen.\n\nZertifikate müssen stimmen.\n\nHeader müssen stimmen.\n\nDienste müssen wissen, dass sie hinter einem Proxy laufen.\n\nUnd vor allem muss man entscheiden, was wirklich von außen erreichbar sein soll.\n\nDenn das Internet ist kein freundlicher Ort.\n\nEs ist eher wie ein Bahnhofsklo mit Glasfaseranschluss.\n\nAlles, was offen ist, wird gefunden.\n\nAlles, was gefunden wird, wird ausprobiert.\n\nAlles, was schlecht konfiguriert ist, wird irgendwann dein Problem.\n\nEin Reverse Proxy hilft, den Eingang zu ordnen.\n\nAber du musst immer noch entscheiden, wen du reinlässt.\n\nOder anders gesagt:\n\nDer Reverse Proxy ist der Türsteher.\n\nAber wenn du die Tür zu allem aufmachst, kann auch der beste Türsteher nur noch müde gucken.",
  "title": "Reverse Proxy: Der Türsteher fürs Homelab, der meistens schuld ist, wenn gar nichts geht",
  "updatedAt": "2026-06-07T12:00:17.202Z"
}