Dlaczego reverse proxy działa poprawnie dla domeny, ale nie działa dla lokalnego adresu IP?

Eva Wong

IceWhale author

Eva Wong jest Technicznym pisarzem i stałym majsterkowiczem w ZimaSpace. Całe życie geek z pasją do homelabów i oprogramowania open-source, specjalizuje się w tłumaczeniu skomplikowanych koncepcji technicznych na przystępne, praktyczne przewodniki. Eva wierzy, że samodzielne hostowanie powinno być zabawą, a nie czymś onieśmielającym. Poprzez swoje samouczki umożliwia społeczności rozwiewanie tajemnic konfiguracji sprzętu, od budowy pierwszego NAS po opanowanie kontenerów Docker.

Why Does a Reverse Proxy Work by Domain but Fail by Local IP?

Reverse proxy działa na podstawie domeny, ponieważ jego reguły routingu i TLS często zależą od żądanej nazwy hosta, a nie tylko od docelowego adresu IP.

Gdy klient domowy otwiera https://app.example.com, DNS dostarcza adres IP, ale przeglądarka nadal przesyła domenę podczas negocjacji TLS i w nagłówku HTTP Host. Otwarcie https://192.168.1.20 zmienia te identyfikatory, więc proxy może wybrać domyślną stronę, odrzucić certyfikat, nie znaleźć ścieżki aplikacji lub przekierować z powrotem na skonfigurowany publiczny URL. Poprawny test zachowuje zamierzoną nazwę hosta, zmieniając tylko docelową sieć.

Porównaj żądanie nazwy hosta z żądaniem bezpośredniego IP

Wyślij jedno żądanie do domeny, a drugie do lokalnego IP, a następnie porównaj kod statusu, certyfikat, nagłówki odpowiedzi, lokalizację przekierowania oraz log dostępu reverse-proxy. Nie zakładaj, że oba żądania są równoważne, ponieważ trafiają do tego samego interfejsu Ethernet.

Przewodnik po reverse-proxy w homelabie wyjaśnia, że proxy analizuje nagłówek HTTP Host, aby kierować kilka usług przez jeden adres IP i port.

Jeśli żądanie domeny pasuje do ścieżki aplikacji, a żądanie IP trafia na stronę domyślną lub 404, proxy działa zgodnie z konfiguracją. Kolejną decyzją jest, czy dostęp bezpośredni do IP jest faktycznie potrzebny, czy lokalny DNS powinien zachować domenę.

Testuj lokalne IP, zachowując zamierzony nagłówek Host

Użyj narzędzia klienckiego, które łączy się z lokalnym adresem IP proxy, wysyłając jednocześnie domenę aplikacji jako nagłówek Host. W przypadku HTTPS zachowaj również domenę jako nazwę serwera TLS, zamiast zastępować ją adresem IP.

Server Fault opisuje, jak HTTP reverse proxy może używać nagłówka Host do wyboru trasy w taki sam sposób jak wirtualne hosty oparte na nazwie.

Jeśli żądanie z wymuszonym hostem powiedzie się, trasa proxy i backend są zdrowe; niepowodzenie przy bezpośrednim IP to niezgodność tożsamości. Jeśli nadal nie działa, sprawdź nasłuchiwacz, lokalną zaporę, punkt wejścia proxy i priorytet trasy przed zmianą DNS.

Sprawdź dopasowanie TLS SNI i certyfikatu

HTTPS dodaje decyzję o nazwie hosta przed żądaniem HTTP. Klient zwykle wysyła Server Name Indication podczas negocjacji TLS, aby proxy mogło wybrać właściwy certyfikat i zabezpieczony wirtualny host.

Implementacja reverse-proxy SNI zauważa, że backendy HTTPS są wybierane na podstawie nazwy SNI klienta zanim można zbadać zwykłe nagłówki HTTP.

Dostęp bezpośredni przez IP może prezentować domyślny certyfikat lub nie przejść walidacji nazwy hosta, nawet gdy proxy jest osiągalne. Używaj domeny z lokalnym DNS lub wdrażaj świadomie zarządzany certyfikat zawierający IP tylko wtedy, gdy HTTPS bezpośrednio na IP jest rzeczywistym wymogiem operacyjnym.

Featured

ZimaCube 2 Osobisty domowy NAS w chmurze

ZimaCube2

Sprawdź stronę domyślną i priorytet trasy

Przeanalizuj, który wirtualny host obsługuje żądania, które nie pasują do skonfigurowanej domeny. Strona domyślna może zwracać panel kontrolny, przekierowywać na inną nazwę hosta, zamykać połączenie lub wyświetlać ogólny błąd.

Dyskusja o Caddy pokazuje, że żądanie może dotrzeć do właściwego adresu IP proxy, podczas gdy nagłówek Host i nazwa TLS nadal decydują, czy wybrany zostanie zamierzony upstream.

Utrzymuj domyślną trasę wyraźną i bezpieczną. Nie dodawaj szerokiego proxy catch-all do jednego backendu tylko po to, by umożliwić dostęp przez IP, ponieważ może to kierować nieznane nazwy hostów lub ruch skanujący do aplikacji, która miała być ograniczona do domeny.

Sprawdź, czy aplikacja przekierowuje do swojej kanonicznej URL

Nawet gdy proxy akceptuje żądanie IP, backend może wymuszać skonfigurowany publiczny URL bazowy i przekierowywać przeglądarkę do domeny. Ciasteczka uwierzytelniające, callbacki OAuth, pochodzenie WebSocket i kontrole CSRF mogą również zależeć od tej kanonicznej nazwy hosta.

Porównaj log proxy z logiem aplikacji i sprawdź nagłówek Location. Przekierowanie do domeny nie jest błędem routingu; to dowód, że aplikacja oczekuje jednej publicznej tożsamości.

Popraw nagłówki forwarded host i protocol, gdy aplikacja generuje błędny zewnętrzny URL. Nie zastępuj kanonicznej domeny prywatnym IP tylko po to, by ominąć przekierowanie, ponieważ może to zepsuć certyfikaty i zdalny dostęp.

Używaj lokalnego DNS, gdy domena jest zamierzonym interfejsem

Utwórz wewnętrzny rekord DNS, który rozwiązuje domenę aplikacji na lokalny adres reverse-proxy. Przeglądarka wtedy korzysta z efektywnej ścieżki LAN, zachowując ten sam nagłówek Host, nazwę SNI, certyfikat, ciasteczka i URL aplikacji.

Porównanie ZimaSpace reverse proxy i prywatnych ścieżek dostępu pomaga zdecydować, czy domena powinna pozostać lokalnym i publicznym punktem wejścia, czy zostać za prywatną siecią.

Problem jest rozwiązany, gdy domena działa zarówno wewnątrz, jak i na zewnątrz dzięki celowym odpowiedziom DNS, podczas gdy bezpośredni IP albo trafia na udokumentowaną stronę domyślną, albo jest celowo odrzucany. Proxy kierujące po domenie nie musi zachowywać się jak serwer jednowitrynowy adresowany po IP.