La source a produit une conception fonctionnelle de proxy inverse local : déplacer le tableau de bord ZimaOS du port 80, réserver les ports 80/443 au proxy inverse, créer des enregistrements DNS locaux et configurer les cibles du proxy Nginx avec l’adresse IP statique du serveur ZimaOS sur le réseau local ainsi que le véritable port de chaque application.
Le choix de conception essentiel était d’éviter une boucle DNS. Les enregistrements Bind9 de l’utilisateur fournissaient des noms conviviaux tels que food.sdak, tandis que la destination en amont de Nginx restait l’adresse IP statique de ZimaOS, par exemple 10.66.66.30:9925, au lieu de renvoyer le proxy vers le nom d’hôte lui-même.
Déplacer l’interface Web de ZimaOS hors du port 80
Dans la source, l’utilisateur a modifié l’interface Web de ZimaOS pour utiliser le port 83. Le choix exact du port secondaire n’est pas important ; choisissez-en un qui est libre et documentez-le.
Après la modification, vérifiez d’abord l’accès direct :
http://ZIMA_LAN_IP:83N’ajoutez pas Nginx tant que la nouvelle URL directe du tableau de bord ne fonctionne pas.
Le port 443 peut nécessiter la même planification
La réponse de la communauté indiquait que les paramètres HTTPS de ZimaOS se trouvent dans le mode développeur et peuvent entrer en conflit avec un proxy inverse qui souhaite également utiliser le port 443. Décidez quel service doit utiliser le port 443 avant d’activer les deux.
Si Nginx gère la terminaison HTTPS, le serveur principal peut rester en HTTP privé sur le réseau local, sauf si votre modèle de sécurité exige le chiffrement TLS sur les deux liaisons.
Utiliser une adresse IP stable du réseau local comme cible du proxy inverse
L’utilisateur de la source a attribué une adresse IP statique à l’hôte ZimaOS et a utilisé cette adresse dans la configuration en amont de Nginx. Les versions actuelles de ZimaOS prennent en charge la configuration réseau DHCP ou statique manuelle dans Paramètres → Réseau.
Consultez le processus actuel de configuration d’une adresse IP statique ZimaOS.
Créer des enregistrements DNS locaux pour des noms conviviaux
Pour un espace de noms DNS réservé au réseau domestique, évitez si possible d’utiliser .local pour le DNS monodiffusion classique, car ce suffixe est traditionnellement utilisé par mDNS. Utilisez votre véritable domaine interne ou un autre espace de noms local géré délibérément.
Pointer Nginx vers des serveurs principaux IP:Port
Cela évite de résoudre le nom d’hôte public ou convivial depuis l’intérieur du même proxy et de renvoyer accidentellement le trafic vers le proxy lui-même.
Préserver le trafic WebSocket/Upgrade pour les applications interactives
ZimaOS et de nombreuses applications auto-hébergées utilisent des connexions WebSocket ou HTTP Upgrade persistantes. Une page peut sembler chargée visuellement alors que les widgets en temps réel ou les boîtes de dialogue de l’application échouent si le proxy inverse ne transmet pas les en-têtes Upgrade requis.
Utilisez la prise en charge WebSocket appropriée de Nginx ou de Nginx Proxy Manager pour les applications qui en ont besoin.
Le DNS local n’exige pas d’exposition à Internet
L’objectif de la source était la commodité locale, et non la publication du NAS sur Internet. Gardez les écouteurs du proxy et les enregistrements DNS limités aux réseaux de confiance, sauf si vous concevez intentionnellement un accès externe avec une authentification, des certificats, des règles de pare-feu et un modèle de menace approprié.
Les redémarrages ont corrigé l’état ARP/réseau dans la source, mais ne constituent pas le cœur de la configuration
L’utilisateur a redémarré ZimaOS et IPFire après avoir modifié les ports et a indiqué que cela avait libéré un état ARP/réseau obsolète. Il s’agissait d’un nettoyage propre à cette source, et non d’une exigence universelle après chaque modification du proxy.
Foire aux questions sur le proxy inverse Nginx
Où la source a-t-elle modifié le port de l’interface Web de ZimaOS ?
Paramètres → Général.
Pourquoi la source a-t-elle utilisé l’adresse IP statique comme destination Nginx ?
Pour éviter une boucle DNS/proxy et rendre la cible du serveur principal déterministe.
Les noms locaux du proxy inverse doivent-ils être exposés à Internet ?
Non. Toute la conception peut rester à l’intérieur du réseau local grâce au DNS local.
