Für den sicheren Zugriff auf mehrere Webdienste genügt eine einzelne HTTPS-Adresse, wenn der Reverse Proxy des Synology NAS die Anfragen anhand des Hostnamens an den passenden Dienst weiterleitet. Betroffen sind dabei vor allem die Ebenen Webserver, Zertifikat, DNS und Netzwerk; die Dateien auf den Volumes bleiben normalerweise unangetastet. Prüfe zuerst, ob der gewünschte Hostname auf deine öffentliche IP-Adresse zeigt und welche Ports am Router ankommen. Bevor diese Grundlagen stimmen, solltest du weder zusätzliche Portfreigaben anlegen noch bestehende Weiterleitungen löschen.
Was der Reverse Proxy auf dem NAS übernimmt
Ein Reverse Proxy nimmt eine eingehende HTTPS-Anfrage entgegen und reicht sie intern an einen Dienst weiter. Nach außen verwendest du beispielsweise cloud.example.net, während der eigentliche Dienst im lokalen Netz unter einer Adresse wie 192.168.1.20:8080 erreichbar ist. Der Browser muss den internen Port dabei nicht kennen.
Die Zuordnung erfolgt meist über drei Angaben: das Protokoll der eingehenden Verbindung, den Hostnamen und den Zielport. Für jede Anwendung legst du eine eigene Regel an. Der Proxy erkennt dann anhand des Hostnamens, welcher interne Dienst die Anfrage erhalten soll.
Das ist etwas anderes als eine einfache Portweiterleitung. Eine Weiterleitung bringt einen Port am Router zu einem Zielgerät im LAN. Der Reverse Proxy entscheidet erst danach, welcher Dienst auf dem NAS angesprochen wird. Dadurch kannst du mehrere Anwendungen über HTTPS bereitstellen, ohne für jede Anwendung einen eigenen öffentlichen Port zu verwenden.
Voraussetzungen vor der Einrichtung
Bevor du im DSM eine Regel erstellst, sollten die technischen Grundlagen feststehen. Ein Reverse Proxy löst weder ein DNS-Problem noch einen fehlenden Dienst und ersetzt auch keine sichere Authentifizierung.
- Der gewünschte DNS-Name muss auf deine öffentliche IP-Adresse zeigen. Bei einer wechselnden IP-Adresse brauchst du eine funktionierende DynDNS-Aktualisierung.
- Der Dienst muss im lokalen Netzwerk erreichbar sein. Teste ihn zunächst direkt mit seiner internen Adresse und seinem internen Port.
- Der Router muss die benötigten externen Ports an das Synology NAS weiterleiten. Üblicherweise werden für HTTPS-Anfragen TCP-Verbindungen auf Port 443 verwendet.
- Eine Firewall darf die Verbindung nicht blockieren. Prüfe sowohl die Router-Regeln als auch die Firewall-Einstellungen des NAS und des Zielgeräts.
- Für den Hostnamen muss ein passendes TLS-Zertifikat vorhanden sein. Ohne gültiges Zertifikat erhältst du Warnungen oder eine nicht vertrauenswürdige Verbindung.
- Der interne Dienst muss mit der Art der Weiterleitung umgehen können. Einige Anwendungen benötigen Einstellungen für den externen Hostnamen oder einen vertrauenswürdigen Proxy.
Wenn du mehrere Subdomains einsetzen möchtest, etwa cloud.example.net und media.example.net, müssen alle Namen korrekt auf den Anschluss zeigen. Ein Wildcard-DNS-Eintrag kann dabei helfen, ersetzt aber nicht das passende Zertifikat und die einzelnen Proxy-Regeln.
Das Zertifikat richtig vorbereiten
HTTPS verschlüsselt die Verbindung zwischen Browser und Reverse Proxy. Damit der Browser dem NAS vertraut, muss das Zertifikat den aufgerufenen Hostnamen abdecken. Ein Zertifikat für nas.example.net passt nicht automatisch zu cloud.example.net.
Öffne im DSM die Zertifikatsverwaltung und prüfe, welches Zertifikat dem jeweiligen Dienst zugeordnet ist. Die genaue Bezeichnung und der Menüpfad können sich je nach DSM-Version unterscheiden. Entscheidend ist die Funktion zur Verwaltung, Erneuerung und Zuordnung von Zertifikaten.
Verwendest du mehrere Subdomains, gibt es zwei verbreitete Varianten: ein Zertifikat mit allen benötigten Namen oder ein Wildcard-Zertifikat für eine gemeinsame Domain-Ebene. Bei einer späteren Erweiterung musst du prüfen, ob der neue Hostname ebenfalls enthalten ist.
Die automatische Erneuerung sollte nach der Einrichtung kontrolliert werden. Ein abgelaufenes Zertifikat kann dazu führen, dass der Dienst plötzlich nicht mehr vertrauenswürdig erreichbar ist, obwohl die Proxy-Regel unverändert funktioniert.
Reverse-Proxy-Regel in DSM anlegen
Die Funktion findest du in DSM je nach Version innerhalb der Anmeldeportal- oder Login-Portal-Einstellungen. Suche dort nach dem Bereich für Reverse Proxy beziehungsweise nach Regeln, die externe Anfragen an interne Ziele weiterleiten. Wenn sich die Menübezeichnung unterscheidet, orientiere dich an der Funktion und nicht an einem festen Pfad.
- Lege eine neue Regel für den gewünschten Dienst an.
- Wähle als Quellprotokoll HTTPS und trage den öffentlichen Hostnamen ein.
- Verwende als Quellport den Port, über den die Anfrage von außen ankommt.
- Wähle als Zielprotokoll HTTP oder HTTPS passend zum internen Dienst.
- Trage die interne IP-Adresse oder den internen DNS-Namen des Zielsystems ein.
- Setze den Zielport auf den Port, auf dem die Anwendung tatsächlich lauscht.
- Speichere die Regel und teste sie zunächst mit einem einzigen Hostnamen.
Bei einem Dienst auf demselben NAS kann als Ziel je nach Aufbau ein lokaler Dienstname oder eine interne Adresse verwendet werden. Bei einem Container musst du zusätzlich prüfen, ob der veröffentlichte Port oder ein internes Docker-Netzwerk angesprochen werden soll. Ein Port, der nur innerhalb eines Containers existiert, ist nicht automatisch vom Reverse Proxy des DSM erreichbar.
Die Pfadangaben sind ebenfalls wichtig. Manche Anwendungen funktionieren nur unter der Root-Adresse einer Subdomain, während andere auch unter einem Unterpfad wie example.net/cloud betrieben werden können. Eine eigene Subdomain ist meist einfacher, weil dadurch weniger Anpassungen an Cookies, Weiterleitungen und Ressourcenpfaden erforderlich sind.
Portfreigaben und Firewall sicher prüfen
Der Router sollte nur die Ports weiterleiten, die du tatsächlich benötigst. Für den öffentlichen HTTPS-Zugriff ist normalerweise eine Weiterleitung von TCP 443 auf das NAS erforderlich. Eine Weiterleitung von HTTP kann für die Zertifikatsausstellung oder eine automatische Umleitung genutzt werden, sollte aber nicht unüberlegt dauerhaft offen bleiben.
Vermeide direkte Freigaben der internen Dienstports. Wenn beispielsweise eine Anwendung intern auf Port 8080 läuft, sollte dieser Port nicht zusätzlich am Router veröffentlicht werden, sofern der Zugriff über den Reverse Proxy genügt. Jede weitere öffentliche Angriffsfläche erhöht den Prüf- und Wartungsaufwand.
Prüfe die Verbindung von außerhalb deines lokalen Netzes, etwa über das Mobilfunknetz. Einige Router unterstützen kein zuverlässiges Hairpin-NAT. Ein Zugriff aus dem WLAN kann deshalb fehlschlagen, obwohl die Erreichbarkeit aus dem Internet funktioniert.
Wenn der Zugriff von außen nicht klappt, kontrolliere die Kette in dieser Reihenfolge:
- Zeigt der DNS-Eintrag auf die aktuelle öffentliche IP-Adresse?
- Erreicht die Portfreigabe den richtigen internen Host?
- Erlaubt die NAS-Firewall die eingehende Verbindung?
- Ist das Zertifikat dem aufgerufenen Hostnamen zugeordnet?
- Existiert die Reverse-Proxy-Regel und verwendet sie den richtigen Zielport?
- Antwortet der interne Dienst direkt aus dem LAN?
Interne Anwendung auf den Proxy vorbereiten
Einige Anwendungen müssen wissen, dass sie hinter einem Proxy betrieben werden. Andernfalls erzeugen sie möglicherweise HTTP- statt HTTPS-Links, lehnen den Hostnamen ab oder funktionieren bei Anmeldung und Datei-Upload nicht korrekt.
Achte in den Einstellungen der Anwendung auf Begriffe wie externe URL, öffentliche Adresse, vertrauenswürdige Domains, Proxy-Unterstützung oder Weiterleitungs-Header. Die genaue Einstellung hängt vom Dienst ab. Trage dort nur Hostnamen ein, die du tatsächlich verwendest, und erlaube nicht pauschal beliebige Domains.
Bei Anwendungen mit WebSockets, Ereignisströmen oder dauerhaft geöffneten Verbindungen muss der Proxy diese Verbindungstypen unterstützen. Typische Hinweise auf ein solches Problem sind eine erreichbare Anmeldeseite, danach aber fehlende Live-Aktualisierungen, abgebrochene Uploads oder eine Sitzung, die sofort endet.
Bei Docker kommt die Netzwerkebene hinzu. Der Reverse Proxy muss den Zielcontainer über einen erreichbaren Namen und Port ansprechen können. Prüfe deshalb, ob der Port am NAS veröffentlicht ist oder ob beide Container im selben Docker-Netzwerk liegen. Achte außerdem darauf, dass der Pfad im Container nicht mit dem Pfad auf dem NAS verwechselt wird.
Typische Fehlerbilder systematisch eingrenzen
Eine Zeitüberschreitung deutet meist auf DNS, Routing, Portfreigabe oder Firewall hin. Erscheint dagegen eine Zertifikatswarnung, erreicht der Browser vermutlich einen TLS-Endpunkt, dem der Hostname oder die Zertifikatskette nicht zugeordnet ist. Eine Antwort mit einem Fehlercode wie 502 weist eher darauf hin, dass der Proxy das interne Ziel nicht erreicht oder keine gültige Antwort erhält.
Rufe den Dienst zunächst direkt im LAN auf. Funktioniert die interne Adresse nicht, liegt die Ursache nicht beim externen Reverse Proxy. Prüfe dann den Dienststatus, den internen Port, die Bind-Adresse und gegebenenfalls die Container-Protokolle.
Funktioniert der direkte Zugriff, aber nicht der externe Hostname, untersuche DNS und Router. Teste anschließend die Proxy-Regel mit genau einem Dienst. Mehrere gleichzeitig geänderte Regeln erschweren die Zuordnung eines Fehlers.
Bei einer Endlosschleife zwischen HTTP und HTTPS solltest du die TLS-Einstellungen des internen Dienstes und die Weiterleitungs-Header prüfen. Der Proxy kann außen HTTPS verwenden, während der Dienst innen HTTP spricht. Wenn die Anwendung diese Trennung falsch interpretiert, leitet sie den Browser unter Umständen immer wieder auf dieselbe Adresse um.
Protokolle helfen bei der Eingrenzung, ersetzen aber keinen Abgleich mit dem tatsächlichen Netzwerkweg. Sichere vor Änderungen Zeitpunkte, Fehlermeldungen und die aktuelle Regelkonfiguration. So kannst du eine funktionierende Einstellung wiederherstellen, falls eine Anpassung unerwartete Auswirkungen hat.
Sicherheitsmaßnahmen für veröffentlichte Dienste
Ein öffentlich erreichbarer Dienst sollte nur dann über das Internet verfügbar sein, wenn du ihn wirklich benötigst. Aktiviere nach Möglichkeit eine Zwei-Faktor-Anmeldung, verwende individuelle starke Passwörter und entferne nicht mehr benötigte Benutzerkonten. Ein Administratorkonto sollte nicht als alltäglicher Benutzer für Webdienste dienen.
Halte DSM, Pakete, Container und die veröffentlichten Anwendungen aktuell. Updates schließen nicht nur Fehler, sondern können auch Änderungen an Proxy-Verhalten, Authentifizierung oder TLS-Unterstützung enthalten. Lies vor größeren Aktualisierungen die Hinweise der jeweiligen Anwendung und stelle sicher, dass du eine Wiederherstellungsmöglichkeit besitzt.
Ein Reverse Proxy ist keine Sicherheitsgarantie. Er verschlüsselt den Transport und ordnet Anfragen weiter, schützt aber nicht automatisch vor schwachen Passwörtern, ungepatchten Anwendungen oder einer falsch konfigurierten Freigabe. Für besonders sensible Dienste kann ein VPN die bessere Zugriffsmethode sein, weil der Dienst dann gar nicht öffentlich erreichbar sein muss.
Überwache Anmeldeversuche und ungewöhnliche Zugriffe. Eine Blockierfunktion gegen wiederholte Fehlanmeldungen kann sinnvoll sein, sollte aber nicht dazu führen, dass du dich selbst dauerhaft aussperrst. Bewahre Wiederherstellungscodes und alternative Administrationswege sicher auf.
Checkliste für die Abnahme
- Der Hostname löst außerhalb des Heimnetzes auf die richtige öffentliche Adresse auf.
- Das Zertifikat enthält den verwendeten Hostnamen und lässt sich erneuern.
- Der interne Dienst antwortet unter seiner lokalen Adresse.
- Die Reverse-Proxy-Regel nutzt den korrekten Zielhost und Zielport.
- Der Zugriff über HTTPS funktioniert aus einem fremden Netz.
- HTTP wird nicht unbeabsichtigt als unverschlüsselte Zugangsmethode verwendet.
- Nicht benötigte direkte Portfreigaben sind entfernt.
- Anmeldung, Datei-Upload, Weiterleitungen und gegebenenfalls WebSockets wurden getestet.
- Die Anwendung kennt ihre externe Adresse und akzeptiert den Hostnamen.
- Backup, Wiederherstellungsschlüssel und Administrationszugang sind weiterhin verfügbar.
Wann ein VPN die bessere Wahl ist
Nicht jeder Dienst muss über eine eigene öffentliche Subdomain erreichbar sein. Für Verwaltungsoberflächen, interne Tools und selten genutzte Anwendungen ist ein VPN oft die sicherere Lösung. Der Dienst bleibt dabei im privaten Netz, während dein Endgerät nach dem Aufbau des Tunnels so zugreifen kann, als befände es sich lokal.
Ein Reverse Proxy eignet sich eher für Anwendungen, die du regelmäßig von unterschiedlichen Geräten aus nutzt und die für einen Webzugriff über HTTPS ausgelegt sind. Die Entscheidung sollte sich am Schutzbedarf, an der Benutzerverwaltung und an der Wartbarkeit orientieren. Je mehr Dienste öffentlich erreichbar sind, desto wichtiger werden Updates, Protokollkontrolle und eine klare Trennung der Zugriffsrechte.
Was nach der Einrichtung wichtig bleibt
Nach dem ersten erfolgreichen Test ist die Arbeit nicht abgeschlossen. Dokumentiere Hostnamen, Zielports, Zertifikatszuordnungen und Router-Regeln. So kannst du nach einem DSM-Update, einem Routertausch oder einer Änderung am Container-Netzwerk schneller prüfen, welche Komponente betroffen ist.
Teste außerdem in regelmäßigen Abständen die Erreichbarkeit und die Anmeldung. Ein funktionierender Zugriff sagt noch nichts darüber aus, ob Backups wiederherstellbar sind oder ob ein Benutzer zu weitreichende Rechte besitzt. Sichere Konfigurationen, Daten und Zugangsmöglichkeiten müssen getrennt betrachtet werden.
Wenn DNS, Zertifikat, Portfreigabe und Zielservice sauber zusammenspielen, erhältst du eine übersichtliche HTTPS-Struktur für mehrere Anwendungen. Bleibt ein Dienst trotz korrekter Grundlagen unerreichbar, solltest du die Anwendung selbst, ihre Proxy-Unterstützung und die interne Netzwerkbindung untersuchen, statt weitere öffentliche Ports freizuschalten.
Häufige Fragen zum Synology Reverse Proxy
Kann der Synology Reverse Proxy mehrere Dienste über dieselbe öffentliche IP-Adresse erreichbar machen?
Ja, mehrere Dienste können dieselbe öffentliche IP-Adresse und denselben HTTPS-Port verwenden, wenn sie unterschiedliche Hostnamen besitzen. DSM ordnet die Anfragen anhand des Hostnamens der passenden Regel und damit dem jeweiligen internen Ziel zu.
Warum erscheint trotz korrekter Reverse-Proxy-Regel ein Zertifikatsfehler?
Häufig deckt das aufgerufene Zertifikat den verwendeten Hostnamen nicht ab oder DSM weist dem Dienst ein anderes Zertifikat zu. Prüfe außerdem, ob du tatsächlich die erwartete Subdomain aufrufst und ob das Zertifikat noch gültig sowie für die automatische Erneuerung vorbereitet ist.
Was bedeutet ein Fehler 502 oder 504 beim Zugriff über den Reverse Proxy?
Diese Fehler weisen meist darauf hin, dass der Proxy den internen Zielservice nicht korrekt erreicht oder keine rechtzeitige Antwort erhält. Teste den Dienst direkt im lokalen Netz, kontrolliere Zieladresse und Zielport und prüfe anschließend Firewall, Container-Netzwerk sowie die Erreichbarkeit des Dienstes vom NAS aus.
Benötigt eine über den Synology Reverse Proxy veröffentlichte Anwendung eigene Proxy-Einstellungen?
Das hängt von der Anwendung ab, weil manche Dienste einen externen Hostnamen, eine vertrauenswürdige Proxy-Adresse oder Unterstützung für WebSockets erwarten. Fehlen diese Einstellungen, können Anmeldung, Weiterleitungen, Datei-Uploads oder einzelne Oberflächenfunktionen trotz erreichbarer Startseite fehlschlagen.
Ist der Synology Reverse Proxy sicherer als eine direkte Portfreigabe für jeden Dienst?
Er kann die öffentliche Angriffsfläche reduzieren, weil mehrere Webdienste über einen zentralen HTTPS-Einstieg erreichbar sind und interne Dienstports nicht einzeln veröffentlicht werden müssen. Er ersetzt jedoch weder Updates, starke Konten und MFA noch die Prüfung, ob ein VPN für besonders sensible Verwaltungs- oder Internedienste besser geeignet ist.