Källan beskrev en fungerande lokal reverse proxy-design: flytta ZimaOS-instrumentpanelen från port 80, reservera portarna 80/443 för reverse proxyn, skapa lokala DNS-poster och ange ZimaOS-serverns statiska LAN-IP samt varje apps faktiska port som mål för Nginx-proxyn.
Det viktigaste designvalet var att undvika en DNS-loop. Användarens Bind9-poster gav lättanvända namn som food.sdak, medan Nginx uppströmsmål fortsatte att vara ZimaOS statiska IP-adress – till exempel 10.66.66.30:9925 – i stället för att proxya värdnamnet tillbaka genom sig självt.
Flytta ZimaOS WebUI från port 80
I källan ändrade användaren ZimaOS WebUI till port 83. Den exakta alternativa porten är inte viktig; välj en ledig port och dokumentera den.
Kontrollera direktåtkomst efter ändringen:
http://ZIMA_LAN_IP:83Lägg inte till Nginx förrän den nya direkta URL:en till instrumentpanelen fungerar.
Port 443 kan kräva samma planering
Svaret i communityn påpekade att ZimaOS HTTPS-inställningar finns under utvecklarläget och kan krocka med en reverse proxy som också vill använda port 443. Bestäm vilken tjänst som ska använda port 443 innan du aktiverar båda.
Om Nginx terminerar HTTPS kan backend-tjänsten fortsätta använda privat HTTP på LAN:et, såvida din säkerhetsmodell inte kräver TLS på båda anslutningssträckorna.
Använd en stabil LAN-IP som mål för reverse proxyn
Källans användare tilldelade ZimaOS-värden en statisk IP-adress och använde den adressen i Nginx-konfigurationens uppströmsmål. Aktuella ZimaOS stöder DHCP eller manuell statisk nätverkskonfiguration under Inställningar → Nätverk.
Se det aktuella arbetsflödet för statisk IP i ZimaOS.
Skapa lokala DNS-poster för lättanvända namn
För ett DNS-namnområde som endast används hemma bör du om möjligt undvika .local för vanlig unicast-DNS, eftersom suffixet traditionellt används av mDNS. Använd din riktiga interna domän eller ett annat medvetet hanterat lokalt namnområde.
Peka Nginx mot backend-tjänster på IP:Port
Detta förhindrar att det vänliga eller offentliga värdnamnet slås upp inifrån samma proxy och av misstag skickar trafiken tillbaka in i proxyn igen.
Vidarebefordra WebSocket-/Upgrade-trafik för interaktiva appar
ZimaOS och många egenhostade appar använder långlivade WebSocket- eller HTTP Upgrade-anslutningar. En sida kan se ut att ha lästs in korrekt medan livekomponenter eller appdialoger slutar fungera om reverse proxyn inte vidarebefordrar de nödvändiga uppgraderingsrubrikerna.
Använd lämpligt WebSocket-stöd i Nginx/Nginx Proxy Manager för applikationer som kräver det.
Lokal DNS kräver inte exponering mot det offentliga Internet
Källans mål var bekvämlighet lokalt, inte att publicera NAS:en på Internet. Begränsa proxylyssnarna och DNS-posterna till betrodda nätverk, såvida du inte avsiktligt utformar extern åtkomst med autentisering, certifikat, brandväggsregler och en lämplig hotmodell.
Omstarter löste ARP-/tillståndsproblem i källan, men är inte en central del av konfigurationen
Användaren startade om både ZimaOS och IPFire efter portändringarna och rapporterade att detta rensade gammalt ARP-/nätverkstillstånd. Det var en källspecifik åtgärd och inte ett universellt krav efter varje proxyändring.
Vanliga frågor om Nginx reverse proxy
Var ändrade källan ZimaOS WebUI-porten?
Inställningar → Allmänt.
Varför använde källan den statiska IP-adressen som Nginx-mål?
För att undvika en DNS-/proxy-loop och göra backend-målet deterministiskt.
Måste lokala reverse-proxy-namn exponeras på Internet?
Nej. Hela designen kan förbli på LAN:et med lokal DNS.
