La fuente produjo un diseño funcional de proxy inverso local: mover el panel de ZimaOS fuera del puerto 80, reservar los puertos 80/443 para el proxy inverso, crear registros DNS locales y configurar los destinos del proxy de Nginx con la IP LAN estática del servidor ZimaOS más el puerto real de cada aplicación.
La decisión de diseño clave fue evitar un bucle DNS. Los registros de Bind9 del usuario proporcionaban nombres descriptivos como food.sdak, mientras que el destino del upstream de Nginx seguía siendo la IP estática de ZimaOS —por ejemplo, 10.66.66.30:9925— en lugar de reenviar el nombre de host hacia sí mismo.
Mueve la interfaz web de ZimaOS fuera del puerto 80
En la fuente, el usuario cambió la interfaz web de ZimaOS al puerto 83. El puerto alternativo exacto no es importante; elige uno que no esté en uso y documenta el cambio.
Después de cambiarlo, confirma primero el acceso directo:
http://ZIMA_LAN_IP:83No añadas Nginx hasta que funcione la nueva URL directa del panel.
El puerto 443 puede requerir la misma planificación
La respuesta de la comunidad señaló que la configuración HTTPS de ZimaOS se encuentra en el Modo desarrollador y puede entrar en conflicto con un proxy inverso que también quiera utilizar el puerto 443. Decide qué servicio será el propietario del puerto 443 antes de habilitar ambos.
Si Nginx termina HTTPS, el backend puede permanecer como HTTP privado en la LAN, salvo que tu modelo de seguridad requiera TLS en ambos tramos.
Usa una IP LAN estable como destino del proxy inverso
El usuario de la fuente asignó una IP estática al equipo con ZimaOS y utilizó esa dirección en la configuración del upstream de Nginx. La versión actual de ZimaOS admite la configuración de red DHCP o manual estática en Configuración → Red.
Consulta el procedimiento actual de ZimaOS para configurar una IP estática.
Crea registros DNS locales para nombres descriptivos
Para un espacio de nombres DNS exclusivo del hogar, evita usar .local para el DNS unicast ordinario siempre que sea posible, porque ese sufijo se utiliza convencionalmente para mDNS. Usa tu dominio interno real u otro espacio de nombres local administrado deliberadamente.
Apunta Nginx a backends IP:Puerto
Esto evita resolver el nombre de host público o descriptivo desde dentro del mismo proxy y enviar accidentalmente el tráfico de vuelta al proxy.
Conserva el tráfico WebSocket/Upgrade para las aplicaciones interactivas
ZimaOS y muchas aplicaciones autohospedadas utilizan conexiones WebSocket o HTTP Upgrade de larga duración. Una página puede parecer cargada visualmente, mientras que los widgets en tiempo real o los cuadros de diálogo de la aplicación fallan si el proxy inverso no reenvía las cabeceras de actualización necesarias.
Usa la compatibilidad adecuada con WebSocket de Nginx/Nginx Proxy Manager para las aplicaciones que la requieran.
El DNS local no requiere exponer el servicio a Internet
El objetivo de la fuente era la comodidad local, no publicar el NAS en Internet. Mantén los escuchas del proxy y los registros DNS restringidos a redes de confianza, salvo que diseñes intencionadamente un acceso externo con autenticación, certificados, reglas de firewall y un modelo de amenazas adecuado.
Los reinicios solucionaron el estado de ARP/red en la fuente, pero no forman parte de la configuración principal
El usuario reinició ZimaOS e IPFire después de cambiar los puertos e informó que esto liberó un estado de ARP/red obsoleto. Fue una limpieza específica de esa situación, no un requisito universal después de cada cambio del proxy.
Preguntas frecuentes sobre el proxy inverso de Nginx
¿Dónde cambió la fuente el puerto de la interfaz web de ZimaOS?
Configuración → General.
¿Por qué utilizó la fuente la IP estática como destino de Nginx?
Para evitar un bucle DNS/proxy y hacer determinista el destino del backend.
¿Es necesario exponer a Internet los nombres del proxy inverso local?
No. Todo el diseño puede permanecer dentro de la LAN con DNS local.
