A fonte produziu um design funcional de proxy inverso local: mover o painel do ZimaOS da porta 80, reservar as portas 80/443 para o proxy inverso, criar registos DNS locais e apontar os destinos do proxy Nginx para o IP estático do servidor ZimaOS na LAN, juntamente com a porta real de cada aplicação.
A principal decisão de design foi evitar um ciclo de DNS. Os registos Bind9 do utilizador forneciam nomes amigáveis, como food.sdak, enquanto o destino upstream do Nginx continuava a ser o IP estático do ZimaOS — por exemplo, 10.66.66.30:9925 — em vez de encaminhar o nome de anfitrião novamente através do próprio proxy.
Mover a WebUI do ZimaOS da Porta 80
Na fonte, o utilizador alterou a WebUI do ZimaOS para a porta 83. A porta alternativa exata não é importante; escolha uma que esteja livre e registe essa informação.
Depois de a alterar, confirme primeiro o acesso direto:
http://ZIMA_LAN_IP:83Não adicione o Nginx até o novo URL direto do painel funcionar.
A Porta 443 Pode Exigir o Mesmo Planeamento
A resposta da comunidade referiu que as definições HTTPS do ZimaOS se encontram no Modo de Programador e podem entrar em conflito com um proxy inverso que também pretenda utilizar a porta 443. Decida qual serviço deve assumir a porta 443 antes de ativar ambos.
Se o Nginx terminar o HTTPS, o backend pode continuar a utilizar HTTP privado na LAN, a menos que o seu modelo de segurança exija TLS em ambos os percursos.
Utilizar um IP Estável da LAN para o Destino do Proxy Inverso
O utilizador da fonte atribuiu um IP estático ao anfitrião ZimaOS e utilizou esse endereço na configuração upstream do Nginx. O ZimaOS atual suporta configuração de rede DHCP ou estática manual em Definições → Rede.
Consulte o procedimento atual para configurar um IP estático do ZimaOS.
Criar Registos DNS Locais para Nomes Amigáveis
Para um espaço de nomes DNS exclusivamente doméstico, evite utilizar .local para DNS unicast normal sempre que possível, pois esse sufixo é convencionalmente utilizado pelo mDNS. Utilize o seu domínio interno real ou outro espaço de nomes local gerido deliberadamente.
Apontar o Nginx para Backends IP:Porta
Isto evita resolver o nome de anfitrião público/amigável a partir do próprio proxy e enviar acidentalmente o tráfego novamente para o proxy.
Preservar o Tráfego WebSocket/Upgrade para Aplicações Interativas
O ZimaOS e muitas aplicações autoalojadas utilizam ligações WebSocket ou HTTP upgrade de longa duração. Uma página pode parecer carregada visualmente, enquanto os widgets em tempo real ou as caixas de diálogo da aplicação falham se o proxy inverso não encaminhar os cabeçalhos de upgrade necessários.
Utilize o suporte WebSocket adequado do Nginx/Nginx Proxy Manager para as aplicações que dele necessitem.
O DNS Local Não Exige Exposição à Internet Pública
O objetivo da fonte era a conveniência local, não publicar o NAS na Internet. Mantenha os listeners do proxy e os registos DNS restritos a redes fidedignas, a menos que conceba intencionalmente um acesso externo com autenticação, certificados, regras de firewall e um modelo de ameaças adequado.
Os Reinícios Corrigiram o Estado ARP/da Rede na Fonte, mas Não Fazem Parte da Configuração Principal
O utilizador reiniciou o ZimaOS e o IPFire depois de alterar as portas e informou que isso libertou o estado ARP/de rede obsoleto. Essa foi uma limpeza específica da fonte, não um requisito universal após cada alteração do proxy.
Perguntas Frequentes sobre o Proxy Inverso Nginx
Onde alterou a fonte a porta da WebUI do ZimaOS?
Definições → Geral.
Porque utilizou a fonte o IP estático como destino do Nginx?
Para evitar um ciclo DNS/proxy e tornar determinístico o destino do backend.
Os nomes locais do proxy inverso precisam de ser expostos à Internet?
Não. Todo o design pode permanecer dentro da LAN com DNS local.
