Die Quelle beschreibt einen funktionierenden lokalen Reverse-Proxy-Aufbau: Das ZimaOS-Dashboard von Port 80 weg verschieben, die Ports 80/443 für den Reverse Proxy reservieren, lokale DNS-Einträge erstellen und die Nginx-Proxy-Ziele auf die statische LAN-IP-Adresse des ZimaOS-Servers sowie den tatsächlichen Port jeder App setzen.
Die wichtigste Designentscheidung bestand darin, eine DNS-Schleife zu vermeiden. Die Bind9-Einträge des Benutzers verwendeten leicht zu merkende Namen wie food.sdak, während das Nginx-Upstream-Ziel weiterhin die statische ZimaOS-IP-Adresse war – beispielsweise 10.66.66.30:9925 –, anstatt den Hostnamen zurück über den Proxy aufzulösen.
ZimaOS-WebUI von Port 80 weg verschieben
In der Quelle änderte der Benutzer den ZimaOS-WebUI-Port auf Port 83. Der genaue alternative Port ist nicht entscheidend. Wählen Sie einen ungenutzten Port und dokumentieren Sie ihn.
Bestätigen Sie danach zunächst den direkten Zugriff:
http://ZIMA_LAN_IP:83Fügen Sie Nginx erst hinzu, wenn die neue direkte Dashboard-URL funktioniert.
Auch Port 443 muss möglicherweise eingeplant werden
Die Community-Antwort wies darauf hin, dass sich die HTTPS-Einstellungen von ZimaOS im Entwicklermodus befinden und mit einem Reverse Proxy kollidieren können, der ebenfalls Port 443 verwenden soll. Entscheiden Sie vor der Aktivierung beider Dienste, welcher Dienst Port 443 verwenden soll.
Wenn Nginx HTTPS beendet, kann das Backend im LAN weiterhin privates HTTP verwenden, sofern Ihr Sicherheitsmodell nicht TLS auf beiden Verbindungsabschnitten erfordert.
Eine stabile LAN-IP als Reverse-Proxy-Ziel verwenden
Der Benutzer aus der Quelle wies dem ZimaOS-Host eine statische IP-Adresse zu und verwendete diese Adresse in der Nginx-Upstream-Konfiguration. Das aktuelle ZimaOS unterstützt die DHCP- oder manuelle statische Netzwerkkonfiguration unter Einstellungen → Netzwerk.
Siehe den aktuellen Ablauf für statische ZimaOS-IP-Adressen.
Lokale DNS-Einträge für leicht zu merkende Namen erstellen
Vermeiden Sie in einem ausschließlich für das Heimnetz bestimmten DNS-Namensraum nach Möglichkeit die Verwendung von .local für gewöhnliches Unicast-DNS, da dieses Suffix üblicherweise für mDNS verwendet wird. Verwenden Sie Ihre echte interne Domain oder einen anderen bewusst verwalteten lokalen Namensraum.
Nginx auf IP:Port-Backends verweisen
Dadurch wird verhindert, dass der öffentliche bzw. leicht zu merkende Hostname innerhalb desselben Proxys aufgelöst und der Datenverkehr versehentlich erneut an den Proxy zurückgesendet wird.
WebSocket-/Upgrade-Datenverkehr für interaktive Apps weiterleiten
ZimaOS und viele selbst gehostete Apps verwenden langlebige WebSocket- oder HTTP-Upgrade-Verbindungen. Eine Seite kann zwar optisch vollständig geladen erscheinen, während Live-Widgets oder App-Dialoge fehlschlagen, wenn der Reverse Proxy die erforderlichen Upgrade-Header nicht weiterleitet.
Verwenden Sie die geeignete WebSocket-Unterstützung von Nginx bzw. Nginx Proxy Manager für Anwendungen, die diese benötigen.
Lokales DNS erfordert keine Veröffentlichung im öffentlichen Internet
Ziel der Quelle war eine praktische Nutzung im lokalen Netzwerk und nicht die Veröffentlichung des NAS im Internet. Beschränken Sie die Proxy-Listener und DNS-Einträge auf vertrauenswürdige Netzwerke, sofern Sie nicht bewusst einen externen Zugriff mit Authentifizierung, Zertifikaten, Firewall-Regeln und einem geeigneten Bedrohungsmodell konzipieren.
Neustarts behoben in der Quelle ARP-/Zustandsprobleme, gehören aber nicht zur grundlegenden Konfiguration
Der Benutzer startete ZimaOS und IPFire nach den Änderungen an Ports neu und berichtete, dass dadurch veraltete ARP-/Netzwerkzustände bereinigt wurden. Dabei handelte es sich um eine quellspezifische Bereinigung und nicht um eine allgemeine Voraussetzung nach jeder Proxy-Änderung.
FAQ zum Nginx-Reverse-Proxy
Wo wurde in der Quelle der ZimaOS-WebUI-Port geändert?
Einstellungen → Allgemein.
Warum verwendete die Quelle die statische IP-Adresse als Nginx-Ziel?
Um eine DNS-/Proxy-Schleife zu vermeiden und das Backend-Ziel eindeutig festzulegen.
Müssen lokale Reverse-Proxy-Namen im Internet veröffentlicht werden?
Nein. Das gesamte Design kann mit lokalem DNS innerhalb des LANs bleiben.
