Für eine sichere Veröffentlichung von Container-Diensten auf deinem NAS brauchst du drei sauber getrennte Bausteine: einen laufenden Nginx Proxy Manager, korrekt erreichbare DNS-Namen und ein gültiges Zertifikat. Bevor du den Container startest, solltest du prüfen, ob deine Dienste intern bereits funktionieren und ob dein Internetanschluss eingehende Verbindungen zulässt. Der erste nicht-destruktive Schritt ist deshalb eine Bestandsaufnahme von NAS, Container-Netzwerk, Ports, DNS und vorhandenen Zertifikaten. Ändere zunächst keine bestehenden Portfreigaben und entferne keine laufenden Container, solange du nicht weißt, welche Anwendungen diese Ports verwenden.
Welche Aufgabe der Proxy Manager auf dem NAS übernimmt
Nginx Proxy Manager dient als vorgeschalteter Reverse Proxy. Er nimmt Anfragen an einer zentralen Adresse entgegen, prüft den angeforderten Hostnamen und leitet die Anfrage an den passenden Dienst im internen Netzwerk weiter. Dadurch muss nicht jeder Container selbst eine eigene öffentliche HTTPS-Konfiguration verwalten.
Ein typischer Aufbau sieht so aus: Du rufst cloud.beispiel.de auf, der DNS-Eintrag zeigt auf deine öffentliche IP-Adresse, und der Proxy Manager leitet die Anfrage intern an einen Container wie Nextcloud weiter. Der Browser sieht dabei nur die öffentliche Adresse. Der eigentliche Dienst kann weiterhin auf einem internen Port wie 8080 oder 9000 laufen.
HTTPS verschlüsselt die Strecke zwischen Browser und Proxy. Damit ist aber nicht automatisch jede Verbindung im internen Netz geschützt. Außerdem ersetzt ein Reverse Proxy weder Authentifizierung noch regelmäßige Updates, Backups, Zugriffsbeschränkungen oder eine sichere Konfiguration des dahinterliegenden Dienstes.
Voraussetzungen vor der Installation
Prüfe vor dem Anlegen des Containers, welche Plattform und welche Container-Verwaltung du verwendest. Synology nutzt häufig Container Manager, QNAP arbeitet je nach System mit Container Station, und andere NAS-Hersteller verwenden eigene Oberflächen oder Docker-kompatible Werkzeuge. Die Bezeichnungen der Menüs können sich je nach Version unterscheiden. Entscheidend sind die Funktionen für Image, Container, Volumes, Netzwerk und Portzuordnung.
- Das NAS sollte eine unterstützte Container-Laufzeit und ausreichend freien Speicher besitzen.
- Die interne Zielanwendung muss im lokalen Netz erreichbar sein.
- Für jede öffentliche Anwendung brauchst du einen eigenen DNS-Namen oder eine passende Subdomain.
- Die öffentliche IP-Adresse muss auf den Anschluss zeigen, an dem die Anfragen ankommen.
- Für die Zertifikatsausstellung müssen die erforderlichen HTTP- oder HTTPS-Anfragen den Proxy erreichen können.
- Du brauchst einen Plan für Backups der Proxy-Konfiguration und der Zertifikatsdaten.
Prüfe außerdem, ob dein Anschluss über eine wechselnde öffentliche IP-Adresse verfügt. Bei dynamischen Adressen kann ein dynamischer DNS-Dienst erforderlich sein. Befindet sich der Anschluss hinter Carrier-Grade-NAT, erreicht eine normale Portfreigabe den Router möglicherweise nicht. In diesem Fall funktionieren klassische öffentliche Zertifikatsprüfungen und eingehende Verbindungen oft nicht ohne zusätzliche Lösung.
Ports, DNS und Netzwerktopologie zuerst klären
Ein häufiger Fehler entsteht, wenn mehrere Komponenten gleichzeitig dieselben Standardports verwenden. Der Proxy benötigt üblicherweise einen HTTP- und einen HTTPS-Port. Diese Ports dürfen auf dem NAS nicht bereits durch eine andere Weboberfläche, einen weiteren Reverse Proxy oder einen anderen Container belegt sein.
Die externe Portnummer muss nicht zwingend der internen Portnummer entsprechen. Für einen sicheren und nachvollziehbaren Aufbau ist es jedoch sinnvoll, öffentliche HTTP- und HTTPS-Anfragen am Router gezielt an die entsprechenden Ports des NAS weiterzuleiten. Verwende keine zusätzlichen offenen Ports für einzelne Webanwendungen, wenn der Dienst ausschließlich über den Proxy erreichbar sein soll.
DNS muss auf die richtige öffentliche Adresse zeigen. Ein interner Test kann trotzdem scheitern, wenn dein Router keinen sogenannten Hairpin-NAT-Zugriff unterstützt. Prüfe deshalb zunächst aus dem lokalen Netz die interne Zielanwendung und teste die öffentliche Adresse anschließend auch über ein externes Mobilfunknetz. So erkennst du, ob ein Fehler im Container, im Router oder im DNS liegt.
Die Datenablage des Containers planen
Die Konfiguration des Proxy Managers sollte nicht ausschließlich im flüchtigen Container-Dateisystem liegen. Lege auf dem NAS einen eigenen Ordner für die persistenten Daten an und binde ihn als Volume in den Container ein. Dadurch bleiben Proxy-Hosts, Zertifikate, Benutzerkonten und Einstellungen bei einem Container-Neustart oder einer Neuerstellung erhalten.
Der genaue interne Zielpfad hängt vom verwendeten Image ab. Nutze deshalb die Dokumentation des tatsächlich ausgewählten Images und verwechsle nicht den NAS-Pfad mit dem Pfad innerhalb des Containers. Der lokale Ordner muss für den Container les- und schreibbar sein. Zu weit gefasste Berechtigungen erhöhen dagegen das Risiko, dass andere Dienste auf sensible Zertifikats- oder Konfigurationsdateien zugreifen.
Speichere die Zugangsdaten des Administratorkontos nicht in frei zugänglichen Notizen oder unverschlüsselten Freigaben. Sichere die persistenten Daten regelmäßig und teste, ob sich daraus eine Wiederherstellung durchführen lässt. Ein Backup allein ist erst dann belastbar, wenn du weißt, welche Dateien und Datenbanken für die Rückkehr zu einem funktionierenden Zustand benötigt werden.
Container anlegen und Netzwerk prüfen
Lade das gewünschte, gepflegte Image über die Container-Verwaltung des NAS. Prüfe vor dem Erstellen, welcher Image-Tag verwendet wird. Ein festgelegter Versionsstand erleichtert nachvollziehbare Updates, während ein ständig wechselndes Tag unerwartete Änderungen einführen kann.
Ordne die persistenten Verzeichnisse zu und veröffentliche nur die Ports, die der Proxy tatsächlich benötigt. Gib keine NAS-Verwaltungsports an den Container weiter. Wenn du ein eigenes Docker-Netzwerk verwendest, müssen sich Proxy und Zielcontainer über dieses Netzwerk erreichen können. Bei einer Zuordnung über die NAS-IP-Adresse muss der Zielport vom Container aus erreichbar sein.
Nach dem Start kontrollierst du zuerst den Containerstatus und anschließend die Protokolle. Suche nach Meldungen zu fehlenden Dateien, nicht erreichbaren Datenbanken, belegten Ports oder Berechtigungsfehlern. Ein laufender Container bedeutet nicht automatisch, dass die Weboberfläche oder die spätere Weiterleitung korrekt funktioniert.
Ersten Proxy Host für einen internen Dienst anlegen
Rufe die Verwaltungsoberfläche über eine interne Adresse auf und ändere das voreingestellte Administratorkennwort. Aktiviere, sofern die verwendete Version diese Funktion anbietet, eine zusätzliche Absicherung des Administrationszugangs. Die Verwaltungsoberfläche sollte nicht ohne zwingenden Grund öffentlich erreichbar sein.
Beim ersten Proxy Host trägst du den vollständigen Hostnamen ein, der später im Browser verwendet wird. Als Ziel wählst du den internen Dienst und hinterlegst dessen erreichbaren Port. Verwende dabei nicht automatisch den Port, über den der Dienst von außen erreichbar wäre. Der Proxy muss den tatsächlichen internen Dienstpfad verwenden.
Schalte WebSocket-Unterstützung nur ein, wenn die Zielanwendung sie benötigt. Das ist beispielsweise bei interaktiven Oberflächen, Benachrichtigungen oder bestimmten Verwaltungsdiensten relevant. Zusätzliche Optionen sollten einen erkennbaren Zweck haben, weil jede unnötige Anpassung die Fehlersuche erschwert.
HTTPS-Zertifikat ausstellen und zuweisen
Für eine verschlüsselte Verbindung benötigt der Proxy ein Zertifikat, das zum verwendeten Hostnamen passt. In der Verwaltungsoberfläche kannst du je nach Version ein Zertifikat über eine ACME-kompatible Zertifizierungsstelle anfordern. Dafür müssen der Hostname öffentlich auflösbar sein und die vorgesehenen Prüfungen den Proxy erreichen.
Verwende nur Hostnamen, die du kontrollierst. Prüfe vor der Anforderung, ob der DNS-Eintrag bereits aktiv ist. Bei einer DNS-Prüfung muss der verwendete Anbieter und die dafür notwendige Berechtigung eingerichtet sein. Welche Methode verfügbar ist, hängt von der Version, dem Image und der Konfiguration deines DNS-Anbieters ab.
Nach der Ausstellung ordnest du das Zertifikat dem passenden Proxy Host zu und aktivierst die Weiterleitung von HTTP auf HTTPS, sofern die Anwendung damit kompatibel ist. Prüfe danach, ob der Browser ein gültiges Zertifikat, den erwarteten Hostnamen und eine verschlüsselte Verbindung anzeigt. Eine Warnung kann auf einen falschen DNS-Eintrag, ein nicht passendes Zertifikat, eine unvollständige Zertifikatskette oder eine zwischengeschaltete Komponente hinweisen.
Typische Fehler systematisch eingrenzen
Eine leere Seite oder ein Gateway-Fehler bedeutet nicht automatisch, dass der Proxy defekt ist. Teste die Ebenen einzeln und ändere immer nur eine Einstellung. Zuerst muss der Zielcontainer intern antworten. Danach prüfst du, ob der Proxy diesen Zielport aus seinem Netzwerk erreicht. Erst anschließend untersuchst du DNS, Router und HTTPS.
- DNS zeigt auf die falsche Adresse: Der Browser erreicht einen anderen Anschluss oder erhält keine passende Antwort.
- Port ist am Router nicht weitergeleitet: Der Proxy bleibt von außen unsichtbar, obwohl er intern läuft.
- Zielport ist falsch: Der Proxy läuft, findet aber den eigentlichen Dienst nicht.
- Container-Netzwerk ist getrennt: Der Proxy kann den Namen oder die interne Adresse des Zielcontainers nicht erreichen.
- Zertifikat passt nicht: Der aufgerufene Hostname stimmt nicht mit dem Zertifikat überein oder die Ausstellung wurde noch nicht abgeschlossen.
Nutze die Protokolle des Proxy-Containers und der Zielanwendung. Vergleiche Zeitstempel, angeforderten Hostnamen und HTTP-Status. Wenn der Proxy keinen Zugriffseintrag erzeugt, liegt das Problem eher vor dem Container, etwa bei DNS, Router oder Firewall. Wenn der Proxy eine Anfrage protokolliert, aber keine Antwort vom Ziel erhält, untersuchst du zuerst Netzwerk, Zieladresse und Zielport.
Sicherheitsregeln für öffentlich erreichbare Dienste
Veröffentliche nur Anwendungen, die für einen externen Zugriff vorgesehen und ausreichend abgesichert sind. Eine Verwaltungsoberfläche direkt ins Internet zu stellen, erhöht die Angriffsfläche erheblich. Für NAS-Administration, SSH und ähnliche Funktionen ist ein VPN in vielen Fällen die bessere Lösung als eine direkte Portfreigabe.
Aktiviere für Benutzerkonten starke, einzigartige Passwörter und Mehrfaktor-Authentifizierung, sofern der jeweilige Dienst sie unterstützt. Halte NAS, Container-Image, Proxy und Zielanwendungen aktuell. Beobachte die Protokolle auf wiederholte Anmeldeversuche und ungewöhnliche Zugriffe.
Ein Reverse Proxy schützt nicht vor Sicherheitslücken in der weitergeleiteten Anwendung. Auch ein gültiges HTTPS-Zertifikat bestätigt nur die Verschlüsselung und die Identität des Hostnamens. Es bestätigt nicht, dass die Anwendung sicher konfiguriert ist oder dass ein Benutzer tatsächlich berechtigt ist.
Wartung, Updates und Wiederherstellung
Plane Updates nicht als spontane Änderung am laufenden System. Sichere zuerst die Konfiguration und prüfe, ob die Zielanwendungen erreichbar bleiben müssen. Bei einem Image-Update solltest du den aktuellen Container, die verwendeten Volume-Zuordnungen, Ports und Umgebungsvariablen dokumentiert haben.
Nach jedem Update testest du mindestens die Verwaltungsoberfläche, einen internen Proxy Host, die HTTPS-Zertifikatsanzeige und eine Anwendung mit besonderem Netzwerkbedarf. Wenn ein Update fehlschlägt, darf der Rückweg nicht davon abhängen, dass du dich an jede frühere Einstellung erinnerst.
Bewahre die Sicherung der Proxy-Daten nicht nur auf demselben NAS auf. Ein Ausfall des NAS könnte sonst gleichzeitig die laufende Konfiguration und ihre Sicherung unbrauchbar machen. Ergänze lokale Sicherungen durch ein getrenntes Ziel und führe gelegentlich einen Wiederherstellungstest durch.
Wann ein VPN die bessere Lösung ist
Ein Proxy ist sinnvoll, wenn eine Webanwendung bewusst über einen eigenen Hostnamen erreichbar sein soll und ihre Anmeldung sowie Aktualisierung zuverlässig abgesichert sind. Für private Administrationsoberflächen, interne Werkzeuge oder selten benötigte Dienste ist ein VPN oft die risikoärmere Variante.
Mit einem VPN bleibt die Anwendung normalerweise aus dem öffentlichen Web erreichbar und wird nur nach erfolgreicher Netzwerkanmeldung zugänglich. Das reduziert die Zahl der direkt exponierten Dienste. Der Proxy kann trotzdem innerhalb des privaten Netzes verwendet werden, etwa um mehrere Anwendungen einheitlich über HTTPS aufzurufen.
Abschließende Prüfliste für den sicheren Betrieb
- Die Zielanwendung funktioniert zuerst über ihre interne Adresse.
- Der Proxy-Container verwendet persistente Speicherpfade.
- Die benötigten Ports sind eindeutig zugeordnet und nicht doppelt belegt.
- DNS zeigt auf die richtige öffentliche Adresse.
- Der externe Zugriff wurde außerhalb des eigenen WLANs getestet.
- Das Zertifikat gehört zum tatsächlich verwendeten Hostnamen.
- Die Weiterleitung verwendet den internen Zielport der Anwendung.
- Die öffentliche Freigabe ist auf notwendige Dienste begrenzt.
- Administrationszugänge sind nicht unnötig aus dem Internet erreichbar.
- Konfiguration und Zertifikatsdaten werden getrennt gesichert.
- Ein Wiederherstellungsweg wurde einmal praktisch geprüft.
Gehe bei der Einrichtung schrittweise vor: erst interner Dienst, dann Container-Netzwerk, danach DNS und Portweiterleitung und zuletzt das Zertifikat. So bleibt nachvollziehbar, welche Ebene bei einem Fehler betroffen ist. Vor einer Änderung an Ports, Volumes oder laufenden Diensten sicherst du die Konfiguration und hältst einen Rückweg bereit.
Häufige Fragen zum Nginx Proxy Manager auf dem NAS
Kann ich den Nginx Proxy Manager auch hinter einer dynamischen öffentlichen IP-Adresse betreiben?
Ja, sofern ein dynamischer DNS-Dienst den Hostnamen regelmäßig auf die aktuelle öffentliche IP-Adresse aktualisiert. Prüfe zusätzlich, ob dein Internetanschluss eingehende Verbindungen zulässt und nicht hinter Carrier-Grade-NAT liegt.
Warum funktioniert die Zertifikatsausstellung trotz korrekter Portfreigabe nicht?
Häufig zeigt der DNS-Eintrag noch auf eine falsche Adresse, der Router leitet den benötigten Port an das falsche Ziel weiter oder ein vorgelagerter Anschluss blockiert die Anfrage. Teste den Hostnamen von außerhalb deines WLANs und kontrolliere anschließend Router-, Container- und Proxy-Protokolle.
Kann der Nginx Proxy Manager mehrere Container auf demselben NAS unterscheiden?
Ja, jeder Proxy Host kann anhand eines eigenen Hostnamens an einen anderen internen Dienst weiterleiten. Die Zielanwendungen dürfen dabei denselben internen Port verwenden, solange sie unter unterschiedlichen Container- oder NAS-Adressen erreichbar sind.
Welche Rechte braucht der Container für seine persistenten Daten?
Der Container benötigt auf dem eingebundenen NAS-Ordner die erforderlichen Lese- und Schreibrechte für Konfiguration, Datenbank und Zertifikate. Vergib nicht pauschal Vollzugriff für alle Benutzer, sondern prüfe die Identität des Container-Prozesses und korrigiere Berechtigungsfehler anhand der Protokolle.
Was passiert mit den Zertifikaten, wenn ich den Proxy-Container neu erstelle?
Bei korrekt eingebundenen persistenten Volumes bleiben Zertifikate und Proxy-Einstellungen normalerweise erhalten, weil sie außerhalb des flüchtigen Container-Dateisystems gespeichert werden. Ohne diese Daten musst du die Konfiguration möglicherweise neu anlegen und Zertifikate erneut ausstellen.
Ist ein Nginx Proxy Manager sicherer als einzelne Portfreigaben für jeden Container?
Ein zentraler Reverse Proxy kann die Zahl der öffentlich geöffneten Ports reduzieren und HTTPS einheitlich bereitstellen. Er beseitigt aber keine Sicherheitslücken der Zielanwendungen, weshalb Updates, starke Konten, MFA und ein getestetes Backup weiterhin erforderlich sind.
Warum ist der Dienst intern erreichbar, aber über den Proxy nicht?
Dann liegt die Ursache meist bei der Zieladresse, dem internen Port, dem Container-Netzwerk oder den Zugriffsrechten zwischen den Containern. Prüfe zuerst, ob der Proxy das Ziel aus seinem eigenen Netzwerk erreicht und ob der konfigurierte Hostname exakt mit der aufgerufenen Adresse übereinstimmt.
Wann sollte ich statt des Nginx Proxy Manager ein VPN verwenden?
Ein VPN ist häufig die bessere Wahl für NAS-Administration, SSH und interne Werkzeuge, die nicht öffentlich erreichbar sein müssen. Es reduziert die direkt aus dem Internet erreichbare Angriffsfläche, während ein Reverse Proxy für bewusst veröffentlichte Webanwendungen mit eigener Domain praktisch sein kann.