Lokalny DNS może zwracać prawidłowy adres IP NAS-a, a mimo to otwierać niewłaściwą usługę, gdy współdzielony odwrotny serwer proxy kieruje nazwę hosta do innego hosta wirtualnego.
Na domowym serwerze ZimaSpace kilka aplikacji może współdzielić jeden adres LAN za pośrednictwem Nginx, Traefik, Caddy lub innego odwrotnego serwera proxy. DNS wybiera tylko docelowy adres IP. Przeglądarka nadal wysyła nazwę hosta przez SNI TLS i nagłówek HTTP Host, a proxy decyduje, który kontener otrzyma żądanie.
Sprawdź, czy odpowiedź Split-DNS jest rzeczywiście zamierzona
Porównaj rekord lokalny z publicznym i potwierdź, że obie nazwy hostów mają kończyć się na tym samym odwrotnym serwerze proxy.
Praktyczny poradnik dotyczący Split-DNS w homelabie na temat Split-DNS może zwracać prywatną ścieżkę pomaga zawęzić ten problem, ponieważ dotyczy tego samego zagadnienia zamiast jedynie definiować podstawowy protokół.
Pozostaw nazwę hosta w przeglądarce bez zmian, zmieniając wyłącznie adres zwracany przez wewnętrzny DNS.
Potwierdź, że proxy kieruje ruchem na podstawie nazwy hosta
Wyślij żądania z oczekiwaną nazwą hosta i porównaj je z dostępem bezpośrednio przez adres IP do tego samego NAS-a.
Praktyczny poradnik dotyczący odwrotnego proxy w homelabie na temat nagłówek Host wybiera backend pomaga zawęzić ten problem, ponieważ dotyczy tego samego zagadnienia zamiast jedynie definiować podstawowy protokół.
Jeśli bezpośrednie otwarcie adresu IP uruchamia domyślną aplikację, a otwarcie nazwy hosta — właściwą aplikację, problem nie leży w DNS; routing hostów wirtualnych działa zgodnie z założeniami.
Sprawdź, czy nagłówek Host jest przepisywany
Sprawdź nagłówki Host i forwarded-host w proxy oraz backendzie.
Praktyczne wyjaśnienie kwestii bezpieczeństwa i HTTP na temat zmiany nagłówka Host może zmienić routing pomaga zawęzić ten problem, ponieważ dotyczy tego samego zagadnienia zamiast jedynie definiować podstawowy protokół.
Popraw wyłącznie warstwę, która przepisuje nazwę hosta. Nie dodawaj zduplikowanych rekordów DNS, aby skompensować błąd routingu HTTP.
Sprawdź SNI TLS przed routingiem HTTP
Wiele aplikacji HTTPS korzystających z jednego adresu IP nadal musi otrzymać nazwę hosta potrzebną do wybrania właściwego certyfikatu i hosta wirtualnego.
Praktyczny poradnik dotyczący SNI na temat SNI wybiera spośród witryn HTTPS na jednym adresie IP pomaga zawęzić ten problem, ponieważ dotyczy tego samego zagadnienia zamiast jedynie definiować podstawowy protokół.
Porównaj nazwę w certyfikacie z trasą backendu. Certyfikat należący do innej aplikacji wskazuje, że wybór został dokonany nieprawidłowo, zanim żądanie dotarło do właściwej usługi.
Sprawdź domyślnego hosta wirtualnego
Jeśli żadna reguła nazwy hosta nie pasuje, wiele serwerów proxy zwraca domyślny serwer, który może należeć do innej aplikacji.
Praktyczny artykuł dotyczący rozwiązywania problemów z Nginx na temat niepasująca nazwa hosta może trafić do domyślnego serwera pomaga zawęzić ten problem, ponieważ dotyczy tego samego zagadnienia zamiast jedynie definiować podstawowy protokół.
Utwórz jawne reguły dla nazw hostów i neutralną odpowiedź domyślną, zamiast pozwalać, aby jedna aplikacja stała się serwerem przechwytującym żądania dla każdej nieznanej domeny.
Oddziel routing DNS od routingu proxy
Traktuj DNS jako mechanizm wyboru adresu, a odwrotne proxy jako mechanizm wyboru aplikacji.
Przystępne wyjaśnienie różnicy między DNS a odwrotnym proxy na temat DNS i odwrotne proxy rozwiązują problemy na różnych warstwach routingu pomaga zawęzić ten problem, ponieważ dotyczy tego samego zagadnienia zamiast jedynie definiować podstawowy protokół.
Wykonaj ponowny test z dokładną nazwą hosta aplikacji z klienta w sieci LAN. Prawidłowy wynik to oczekiwany certyfikat, trasa proxy i backend — bez zakładek z bezpośrednim adresem IP.
Powtórz test dokładnej ścieżki do serwera domowego
Po zmianie jednej zmiennej powtórz ten sam przepływ pracy z NAS-em lub usługą hostowaną samodzielnie, używając tego samego klienta, zamiast przełączać się na inny test, który może korzystać z innej ścieżki.
Powiązany poradnik ZimaSpace na temat powiązanej ścieżki sieciowej serwera domowego pomaga zachować powiązanie końcowej weryfikacji z tym samym środowiskiem usług hostowanych samodzielnie.
Naprawę można uznać za zakończoną dopiero wtedy, gdy pierwotny objaw pozostaje usunięty po ponownym połączeniu, restarcie usługi oraz drugim kontrolowanym transferze lub żądaniu.
Wsparcie i wskazówki
Więcej do przeczytania

Czy Plex może współdzielić kartę graficzną z innym kontenerem Dockera?
Plex i inny kontener często mogą korzystać z tego samego układu GPU, ale należy przetestować obsługę sterowników, mapowanie urządzeń, obciążenie silnika wideo, pamięć oraz...

Jak ustalić, czy błąd Plex pochodzi od klienta, czy od serwera
Odtwórz ten sam przypadek na innym kliencie, porównaj ścieżkę sesji, a następnie zbierz dowody z serwera dopiero wtedy, gdy zakres analizy wskaże, gdzie faktycznie...

Jak skonfigurować pamięć podręczną Plex i tymczasową pamięć na transkodowane pliki
Chroń trwały stan Plex, umieszczając tymczasowe pliki transkodowania na odpowiedniej pamięci lokalnej, a następnie zweryfikuj czyszczenie, ilość wolnego miejsca i zachowanie podczas ponownego uruchamiania.

