Źródło przedstawia działający projekt lokalnego reverse proxy: przenieś panel ZimaOS z portu 80, zarezerwuj porty 80/443 dla reverse proxy, utwórz lokalne rekordy DNS i ustaw cele proxy Nginx na statyczny adres IP serwera ZimaOS w sieci LAN oraz rzeczywisty port każdej aplikacji.
Kluczową decyzją projektową było uniknięcie pętli DNS. Rekordy Bind9 użytkownika zawierały przyjazne nazwy, takie jak food.sdak, natomiast adres docelowy upstreamu Nginx pozostał statycznym adresem IP ZimaOS — na przykład 10.66.66.30:9925 — zamiast kierowania proxy z powrotem na nazwę hosta.
Przenieś WebUI ZimaOS z portu 80
W źródle użytkownik zmienił port WebUI ZimaOS na 83. Dokładny port alternatywny nie ma znaczenia; wybierz nieużywany port i udokumentuj go.
Po zmianie najpierw potwierdź bezpośredni dostęp:
http://ZIMA_LAN_IP:83Nie dodawaj Nginx, dopóki nowy bezpośredni adres panelu nie zacznie działać.
Port 443 może wymagać takiego samego zaplanowania
W odpowiedzi społeczności zaznaczono, że ustawienia HTTPS ZimaOS znajdują się w trybie deweloperskim i mogą kolidować z reverse proxy, które również chce korzystać z portu 443. Przed włączeniem obu usług zdecyduj, która z nich ma zarządzać portem 443.
Jeśli Nginx kończy połączenia HTTPS, backend może pozostać prywatnym serwerem HTTP w sieci LAN, chyba że model bezpieczeństwa wymaga szyfrowania TLS na obu odcinkach.
Użyj stabilnego adresu IP w sieci LAN jako celu reverse proxy
Użytkownik w źródle przypisał hostowi ZimaOS statyczny adres IP i użył go w konfiguracji upstreamu Nginx. Obecna wersja ZimaOS obsługuje konfigurację sieci DHCP lub ręczne ustawienie statycznego adresu w Ustawienia → Sieć.
Zobacz aktualną procedurę konfiguracji statycznego adresu IP ZimaOS.
Utwórz lokalne rekordy DNS dla przyjaznych nazw
W przypadku przestrzeni nazw DNS używanej wyłącznie w domu unikaj, jeśli to możliwe, używania .local dla zwykłego jednowyborczego DNS, ponieważ ten przyrostek jest tradycyjnie używany przez mDNS. Użyj swojej rzeczywistej domeny wewnętrznej albo innej celowo zarządzanej lokalnej przestrzeni nazw.
Skieruj Nginx na backendy IP:port
Pozwala to uniknąć rozpoznawania publicznej/przyjaznej nazwy hosta wewnątrz tego samego proxy i przypadkowego skierowania ruchu z powrotem do proxy.
Zachowaj ruch WebSocket/Upgrade dla interaktywnych aplikacji
ZimaOS i wiele aplikacji hostowanych samodzielnie korzysta z długotrwałych połączeń WebSocket lub HTTP upgrade. Strona może wyglądać na załadowaną, podczas gdy dynamiczne widżety lub okna dialogowe aplikacji nie działają, jeśli reverse proxy nie przekazuje wymaganych nagłówków upgrade.
W przypadku aplikacji, które tego wymagają, włącz odpowiednią obsługę WebSocket w Nginx/Nginx Proxy Manager.
Lokalny DNS nie wymaga publicznego udostępniania w Internecie
Celem opisanym w źródle była wygoda lokalnego dostępu, a nie publikowanie serwera NAS w Internecie. Ogranicz nasłuchiwanie proxy i rekordy DNS do zaufanych sieci, chyba że celowo projektujesz dostęp zewnętrzny z uwierzytelnianiem, certyfikatami, regułami zapory sieciowej i odpowiednio przeanalizowanym modelem zagrożeń.
Ponowne uruchomienia usunęły stan ARP/sieciowy w źródle, ale nie są podstawowym elementem konfiguracji
Po zmianie portów użytkownik uruchomił ponownie ZimaOS i IPFire oraz zgłosił, że zwolniło to nieaktualny stan ARP/sieciowy. Było to działanie porządkowe specyficzne dla tego przypadku, a nie uniwersalny wymóg po każdej zmianie konfiguracji proxy.
Często zadawane pytania dotyczące reverse proxy Nginx
Gdzie w źródle zmieniono port WebUI ZimaOS?
Ustawienia → Ogólne.
Dlaczego w źródle użyto statycznego adresu IP jako miejsca docelowego Nginx?
Aby uniknąć pętli DNS/proxy i zapewnić jednoznaczny cel backendu.
Czy lokalne nazwy reverse proxy muszą być udostępniane w Internecie?
Nie. Cały projekt może pozostać wewnątrz sieci LAN z lokalnym DNS.
