Dlaczego odwrotny serwer proxy przekierowuje jedną aplikację do domeny innej aplikacji?

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 Redirect One App to Another App’s Domain? - Zima Store Online

Reverse proxy może przekierować jedną aplikację do domeny innej aplikacji, gdy backend lub middleware tworzy przekierowania na podstawie niewłaściwej publicznej nazwy hosta.

W samodzielnie hostowanym środowisku ZimaSpace kilka aplikacji może korzystać z tego samego proxy, a każda z nich może oczekiwać własnego publicznego bazowego adresu URL. Jeśli Host, X-Forwarded-Host, schemat, middleware lub kanoniczny adres URL na poziomie aplikacji wskazuje inną usługę, pierwsza strona może wczytać się prawidłowo, a kolejne przekierowanie 301, 302 lub zwrotne przekierowanie logowania może zmienić domenę.

Sprawdź host i schemat przekazywane do backendu

Podczas odtwarzania przekierowania przechwyć nagłówki żądania w proxy i backendzie.

Praktyczny przewodnik dotyczący implementacji reverse proxy na temat przekazywania hosta i schematu do backendu pomaga wyodrębnić tę gałąź problemu, ponieważ dotyczy tego samego szczegółowego zagadnienia, zamiast jedynie definiować podstawowy protokół.

Najpierw popraw nagłówki proxy, a dopiero potem zmieniaj adresy URL aplikacji. Backend nie może utworzyć prawidłowego bezwzględnego przekierowania, jeśli uważa, że żądanie użyło innego hosta.

Sprawdź w szczególności X-Forwarded-Host

Niektóre frameworki używają nagłówka X-Forwarded-Host zamiast surowego nagłówka Host podczas generowania bezwzględnych adresów URL.

Skoncentrowane wyjaśnienie dotyczące nagłówka HTTP na temat zachowywania publicznej nazwy hosta przez X-Forwarded-Host pomaga wyodrębnić tę gałąź problemu, ponieważ dotyczy tego samego szczegółowego zagadnienia, zamiast jedynie definiować podstawowy protokół.

Porównaj ten nagłówek w działającej aplikacji i aplikacji, która przekierowuje w niewłaściwe miejsce. Usuń globalne nadpisania wymuszające jedną domenę dla każdego backendu.

Sprawdź, czy aplikacja generuje bezwzględne adresy URL

Poszukaj ustawień frameworka, które ufają nagłówkom proxy i tworzą kanoniczne odnośniki lub przekierowania.

Praktyczny blog dotyczący debugowania proxy w rzeczywistych wdrożeniach na temat błędnych bezwzględnych adresów URL za proxy pomaga wyodrębnić tę gałąź problemu, ponieważ dotyczy tego samego szczegółowego zagadnienia, zamiast jedynie definiować podstawowy protokół.

Napraw zaufanie frameworka do proxy lub ustawienie publicznego adresu URL, zamiast przepisywać każde przekierowanie na brzegu sieci.

-15% OFF

ZimaBoard 2 – Mini serwer domowy dla Twojego wielkiego pomysłu

Single board computer zimaboard2

Zweryfikuj bazowy adres URL aplikacji lub domenę kanoniczną

Wiele samodzielnie hostowanych aplikacji przechowuje adres URL witryny niezależnie od reguły proxy.

Praktyczne studium przypadku aplikacji działającej za proxy na temat nadpisywania nazwy hosta proxy przez bazowy adres URL aplikacji pomaga wyodrębnić tę gałąź problemu, ponieważ dotyczy tego samego szczegółowego zagadnienia, zamiast jedynie definiować podstawowy protokół.

Po migracjach lub przywracaniu kopii porównaj zapisane wartości adresu URL aplikacji. Jedna skopiowana baza danych może zawierać kanoniczną nazwę hosta z innego środowiska aplikacji.

Przeanalizuj middleware przekierowań przed backendem

Reguła proxy może celowo zmienić schemat lub host, zanim żądanie w ogóle dotrze do aplikacji.

Praktyczny poradnik dotyczący Traefika w homelabie na temat zastępowania hosta przez middleware przekierowań pomaga wyodrębnić tę gałąź problemu, ponieważ dotyczy tego samego szczegółowego zagadnienia, zamiast jedynie definiować podstawowy protokół.

Na czas jednego testu wyłącz tylko podejrzane middleware przekierowań dla jednego routera. Wymuszanie HTTPS trzymaj oddzielnie od przekierowań między domenami.

Sprawdź adresy URL zwrotnego przekierowania OAuth i OIDC

Przepływy uwierzytelniania często ujawniają niewłaściwą publiczną nazwę hosta, ponieważ dostawca sprawdza dokładny identyfikator URI przekierowania.

Skoncentrowany artykuł dotyczący rozwiązywania problemów z OIDC na temat zależności callbacków OIDC od publicznego adresu URL proxy pomaga wyodrębnić tę gałąź problemu, ponieważ dotyczy tego samego szczegółowego zagadnienia, zamiast jedynie definiować podstawowy protokół.

Porównaj jednocześnie wystawcę, callback, przekazywane nagłówki i bazowy adres URL aplikacji. Prawidłowe wczytanie zwykłej strony nie dowodzi, że ścieżka callbacku logowania działa poprawnie.

Ponownie przetestuj dokładną ścieżkę serwera domowego

Po zmianie jednej zmiennej powtórz ten sam przebieg pracy z NAS-em lub środowiskiem samodzielnie hostowanym, korzystając z tego samego klienta, zamiast przełączać się na inny test, który może używać innej ścieżki.

Powiązany przewodnik ZimaSpace na temat powiązanej ścieżki sieci serwera domowego pomaga zachować weryfikację końcową w tym samym samodzielnie hostowanym środowisku.

Naprawę można uznać za zakończoną dopiero wtedy, gdy pierwotny objaw nie powróci po ponownym połączeniu, restarcie usługi oraz drugim kontrolowanym transferze lub żądaniu.

Często zadawane pytania

Czy DNS może powodować przekierowanie HTTP 301 lub 302?

DNS zwraca tylko adres. Przekierowanie jest generowane przez proxy, warstwę uwierzytelniania lub aplikację.

Dlaczego właściwa aplikacja wczytuje się, zanim przeglądarka zmieni domenę?

Początkowa trasa proxy może być prawidłowa, podczas gdy backend generuje późniejsze bezwzględne przekierowanie na podstawie niewłaściwego bazowego adresu URL lub przekazanego hosta.