La fonte ha prodotto una configurazione funzionante di reverse proxy locale: spostare la dashboard di ZimaOS lontano dalla porta 80, riservare le porte 80/443 al reverse proxy, creare record DNS locali e impostare le destinazioni proxy di Nginx sull'indirizzo IP LAN statico del server ZimaOS più la porta effettiva di ciascuna app.
La scelta progettuale fondamentale è stata evitare un loop DNS. I record Bind9 dell'utente fornivano nomi intuitivi come food.sdak, mentre la destinazione upstream di Nginx rimaneva l'IP statico di ZimaOS, ad esempio 10.66.66.30:9925, invece di reinviare il proxy al nome host passando attraverso sé stesso.
Spostare la WebUI di ZimaOS dalla porta 80
Nella fonte, l'utente ha spostato la WebUI di ZimaOS sulla porta 83. La porta alternativa esatta non è importante; scegline una non utilizzata e documentala.
Dopo la modifica, verifica prima l'accesso diretto:
http://ZIMA_LAN_IP:83Non aggiungere Nginx finché il nuovo URL diretto della dashboard non funziona.
Anche la porta 443 potrebbe richiedere la stessa pianificazione
La risposta della community osservava che le impostazioni HTTPS di ZimaOS si trovano nella Modalità sviluppatore e possono entrare in conflitto con un reverse proxy che vuole usare anch'esso la porta 443. Decidi quale servizio dovrà gestire la porta 443 prima di abilitarli entrambi.
Se Nginx termina HTTPS, il backend può rimanere in HTTP privato sulla LAN, a meno che il tuo modello di sicurezza non richieda TLS su entrambi i collegamenti.
Usare un IP LAN stabile per la destinazione del reverse proxy
L'utente della fonte ha assegnato un IP statico all'host ZimaOS e ha utilizzato quell'indirizzo nella configurazione upstream di Nginx. Le versioni attuali di ZimaOS supportano la configurazione di rete DHCP o manuale con IP statico in Impostazioni → Rete.
Consulta la procedura attuale per l'IP statico di ZimaOS.
Creare record DNS locali per i nomi intuitivi
Per uno spazio dei nomi DNS destinato esclusivamente alla rete domestica, evita, quando possibile, di usare .local per il normale DNS unicast, poiché questo suffisso è convenzionalmente utilizzato da mDNS. Usa il tuo dominio interno reale o un altro spazio dei nomi locale gestito intenzionalmente.
Indirizzare Nginx ai backend IP:Porta
In questo modo si evita di risolvere dall'interno dello stesso proxy il nome host pubblico/intuitivo e di reinviare accidentalmente il traffico al proxy stesso.
Preservare il traffico WebSocket/Upgrade per le app interattive
ZimaOS e molte app self-hosted utilizzano connessioni WebSocket o HTTP upgrade di lunga durata. Una pagina può sembrare caricata correttamente mentre widget dinamici o finestre di dialogo dell'app non funzionano, se il reverse proxy non inoltra le intestazioni di upgrade necessarie.
Usa il supporto WebSocket appropriato di Nginx/Nginx Proxy Manager per le applicazioni che lo richiedono.
Il DNS locale non richiede l'esposizione a Internet
L'obiettivo della fonte era la praticità locale, non pubblicare il NAS su Internet. Mantieni i listener del proxy e i record DNS limitati alle reti attendibili, a meno che tu non progetti intenzionalmente l'accesso esterno con autenticazione, certificati, regole firewall e un modello di minaccia adeguato.
I riavvii hanno risolto lo stato ARP/di rete nella fonte, ma non fanno parte della configurazione fondamentale
L'utente ha riavviato sia ZimaOS sia IPFire dopo aver modificato le porte e ha riferito che questo ha liberato lo stato ARP/di rete obsoleto. Si è trattato di una pulizia specifica di quella configurazione, non di un requisito universale dopo ogni modifica al proxy.
Domande frequenti sul reverse proxy Nginx
Dove ha modificato la fonte la porta della WebUI di ZimaOS?
Impostazioni → Generali.
Perché la fonte ha usato l'IP statico come destinazione di Nginx?
Per evitare un loop DNS/proxy e rendere deterministica la destinazione del backend.
I nomi del reverse proxy locale devono essere esposti a Internet?
No. L'intera configurazione può rimanere all'interno della LAN con DNS locale.
