Jak naprawić odwrotny serwer proxy, który po dodaniu reguły domyślnej kieruje jedną domenę do niewłaściwej aplikacji

Reverse proxy może kierować jedną domenę do niewłaściwej aplikacji, gdy nowa trasa typu catch-all dopasowuje się szerzej lub ma wyższy priorytet niż zamierzona reguła hosta.

To węższy problem niż ogólne przekierowanie do niewłaściwej domeny lub problem z DNS. Kluczowy test polega na sprawdzeniu, czy poprawna domena nadal dociera do oczekiwanego adresu IP proxy i certyfikatu, ale proxy wybiera niewłaściwy backend dopiero po utworzeniu nowej domyślnej trasy. Przed zmianą DNS, bazowych adresów URL aplikacji lub certyfikatów porównaj dopasowania tras i ich priorytety.

Udowodnij, że reguła catch-all zmieniła wybór backendu

Wyślij żądanie do tej samej domeny przed wyłączeniem i po wyłączeniu wyłącznie nowej trasy catch-all lub domyślnej. Zapisz dziennik dostępu proxy, wybrany router lub blok serwera, adres backendu, znacznik odpowiedzi oraz certyfikat.

Praktyczny przewodnik po domyślnym serwerze Nginx ostrzega, że reguły catch-all mogą przechwytywać ruch, nawet gdy istnieje już kilka jawnych hostów wirtualnych.

Jeśli wyłączenie trasy zapasowej natychmiast przywróci właściwą aplikację, pozostaw DNS i aplikację backendową bez zmian. Następnym krokiem jest zapewnienie zwycięstwa konkretnej trasie bez usuwania bezpiecznego mechanizmu zapasowego dla nieznanych nazw hostów.

Sprawdź, czy reguła konkretnego hosta nadal dopasowuje się dokładnie

Porównaj żądaną nazwę hosta z regułą zamierzonej trasy znak po znaku, uwzględniając subdomenę, granice symboli wieloznacznych, końcowe kropki w narzędziach testowych oraz to, czy reguła nasłuchuje na tym samym punkcie wejścia HTTP lub HTTPS co trasa catch-all.

Przewodnik po reverse proxy dla wielu aplikacji pokazuje, że reguły nazw hostów wybierają różne backendy tylko wtedy, gdy przychodzący host pasuje do reguły faktycznie załadowanej przez proxy.

Popraw niepełny lub błędnie wpisany selektor hosta przed zmianą priorytetu. Podniesienie priorytetu reguły, która nigdy się nie dopasowuje, tylko utrudni zrozumienie konfiguracji.

Porównaj priorytet trasy z trasą catch-all

W przypadku proxy obsługujących jawny lub wyliczany priorytet sprawdź, która reguła zwycięża, gdy zarówno konkretny host, jak i szeroka trasa zapasowa mogą dopasować się do tego samego żądania. Zapisz ocenioną regułę, a nie tylko kolejność w pliku konfiguracyjnym.

Przykład catch-all w Traefik celowo nadaje trasie zapasowej niższy priorytet niż rzeczywiste trasy, dzięki czemu konkretne usługi są oceniane jako pierwsze.

Ustaw trasę zapasową poniżej wszystkich zamierzonych tras aplikacji i wykonaj ponowny test. Nie rozwiązuj problemu, przypisując wszystkim routerom arbitralnie ogromne liczby; zachowaj prosty, udokumentowany schemat priorytetów, który przetrwa dodawanie kolejnych aplikacji.

-15% OFF

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

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Sprawdź domyślny serwer w proxy w stylu Nginx

W konfiguracjach Nginx i podobnych ustal, który blok serwera staje się domyślny dla danego adresu i portu nasłuchu, gdy nie zostanie znalezione dopasowanie nazwy hosta. Pierwszy załadowany blok może stać się trasą zapasową, jeśli nie zdefiniowano jawnego serwera domyślnego.

Skoncentrowany artykuł dotyczący rozwiązywania problemów z Nginx wyjaśnia, dlaczego niedopasowane hosty trafiają do serwerów domyślnych, zamiast być po cichu odrzucane.

Użyj neutralnej odpowiedzi domyślnej lub usługi błędu zamiast ustawiania prawdziwej aplikacji jako trasy zapasowej. Dzięki temu nieznana lub błędnie wpisana nazwa hosta nie ujawni przypadkowo innej samodzielnie hostowanej aplikacji.

Sprawdź osobno trasy zapasowe HTTP i HTTPS

Trasa catch-all dodana dla portu 80 nie musi działać tak samo na porcie 443. Routing TLS, SNI, oddzielne punkty wejścia lub druga trasa catch-all mogą powodować, że tylko żądania HTTPS trafiają do niewłaściwej aplikacji.

Przypadek rozwiązywania problemów z Caddy opisuje różne działanie catch-all w zależności od schematu i pokazuje, dlaczego trasę zależną od schematu należy testować bezpośrednio.

Wyślij żądania HTTP i HTTPS z tą samą nazwą hosta i zapisz wybrany moduł obsługi. Napraw trasę zapasową na dotkniętym punkcie wejścia zamiast zmieniać działającą ścieżkę protokołu.

Zachowaj neutralną trasę zapasową i ponownie przetestuj każdą znaną domenę

Po skorygowaniu zakresu dopasowania lub priorytetu spraw, aby trasa zapasowa zwracała neutralny błąd 404, 421 albo kontrolowaną stronę błędu, zamiast przekazywać każdą nieznaną nazwę hosta do jednej aplikacji produkcyjnej. Następnie przetestuj każdą znaną samodzielnie hostowaną domenę.

Przegląd architektury reverse proxy podkreśla, że proxy decyduje o backendzie po dotarciu żądania do proxy, dlatego sama poprawność DNS nie potwierdza poprawności routingu.

Naprawa jest zakończona, gdy każda znana nazwa hosta dociera do zamierzonej aplikacji, a nieznana nazwa hosta trafia wyłącznie do neutralnej trasy zapasowej. Powiązany artykuł ZimaSpace dotyczący reverse proxy przekierowującego do innej domeny jest kolejną ścieżką, gdy proxy wybiera właściwy backend, ale aplikacja później zmienia domenę.

Najczęściej zadawane pytania

Czy DNS może sprawić, że trasa catch-all wygra?

DNS może skierować żądanie do niewłaściwego adresu IP proxy, ale gdy poprawne proxy otrzyma zamierzoną nazwę hosta, dopasowanie trasy jest decyzją proxy. Zweryfikuj obie warstwy osobno.

Czy trasa catch-all powinna przekazywać żądania do aplikacji panelu?

Zwykle nie. Neutralny cel błędu jest bezpieczniejszy, ponieważ literówki i nieznane nazwy hostów nie ujawnią przypadkowo prawdziwej aplikacji administracyjnej ani multimedialnej.

Dlaczego tylko HTTPS trafia do niewłaściwej aplikacji?

HTTPS może korzystać z innego nasłuchującego procesu, ścieżki SNI, witryny certyfikatu lub reguły zapasowej niż HTTP. Przed zmianą globalnego routingu przetestuj oba punkty wejścia niezależnie.