Zbyt wiele przekierowań: znajdź pętlę i ją przerwij
Zbyt wiele przekierowań (ERR_TOO_MANY_REDIRECTS)
Zbyt wiele przekierowań: napraw pętle ERR_TOO_MANY_REDIRECTS | We.Inc
Wklej swoje reguły przekierowań i obserwuj, jak działają krok po kroku, aż pokaże się pętla. Omawia pętle HTTPS za proxy, pętle www i pętle ciasteczek, wraz z poprawkami.
ERR_TOO_MANY_REDIRECTS pojawia się, gdy strona ciągle odsyła przeglądarkę pod inny adres, który w końcu odsyła ją z powrotem, więc łańcuch nigdy się nie kończy i przeglądarka się poddaje. Zwykle winne są dwie warstwy, które wymuszają HTTPS lub www w przeciwnych kierunkach. Napraw to tak, aby każde przekierowanie należało do dokładnie jednej warstwy.
Pętle stojące za większością błędów zbyt wielu przekierowań
Pętla
Jak powstaje
Poprawka
HTTPS za proxy
Proxy łączy się z serwerem przez zwykłe HTTP, a serwer znowu przekierowuje na HTTPS
Przekierowuj na podstawie X-Forwarded-Proto albo tylko na proxy
www kontra domena bez www
Jedna warstwa dodaje www, inna je usuwa
Wybierz jeden host i przekierowuj na niego w jednym miejscu
Pętla ciasteczka lub logowania
Strona logowania wysyła Cię na stronę konta, która odsyła Cię z powrotem, bo ciasteczko się nie zapisało
Sprawdź flagi Domain, Path i Secure ciasteczka
Ukośnik na końcu
Jedna reguła dodaje ukośnik, inna go usuwa
Wybierz jedną formę dla każdego adresu URL
Zapisz każde przekierowanie wykonywane przez Twoją stronę w osobnej linii jako from -> to, wpisz adres początkowy, a symulator podąży za łańcuchem tak, jak zrobiłaby to przeglądarka. Zatrzymuje się, gdy adres się powtórzy, gdy żadna reguła nie pasuje albo po 20 przeskokach, czyli limicie z Fetch Standard.
Wypisz wszystkie znane Ci przekierowania: konfigurację serwera, panel hostingu, reguły CDN, kod aplikacji.
Zapisz je po jednym w linii jako pełne adresy połączone przez ->.
Wpisz adres, który nie działa w przeglądarce, i przeczytaj listę przeskoków.
Usuń lub zmień regułę, która odsyła łańcuch do adresu, który już odwiedził.
Przed ponownym testem wyczyść ciasteczka dla tej strony. Nieaktualne ciasteczko może podtrzymywać pętlę logowania nawet po poprawieniu konfiguracji.
Przeglądarki zapamiętują przekierowania 301 w cache. Testuj poprawki w oknie prywatnym albo użyj curl -I, aby zobaczyć każdą odpowiedź bez cache.
Przekierowuj od razu na adres docelowy. http://example.com powinien trafić na https://www.example.com w jednym przeskoku, a nie przez dwa.
Gdy CDN lub hosting oferuje przełącznik wymuszania HTTPS, użyj go albo reguły na serwerze, nigdy obu naraz bez sprawdzenia, jak współdziałają.
Najczęściej zadawane pytania
Co oznacza komunikat o zbyt wielu przekierowaniach?
Ten komunikat i kod błędu ERR_TOO_MANY_REDIRECTS opisują to samo: strona odpowiadała przekierowaniem za przekierowaniem, a przeglądarka przestała za nimi podążać. Na Twoim komputerze nic nie jest zepsute, choć nieaktualne ciasteczko może być częścią pętli.
Ile przekierowań wykonuje przeglądarka?
Fetch Standard, który implementują przeglądarki, zwraca błąd sieci, gdy liczba przekierowań żądania osiągnie 20.
Dlaczego wymuszanie HTTPS powoduje pętlę za proxy lub CDN?
Odwiedzający łączy się przez HTTPS, ale proxy przekazuje żądanie do Twojego serwera przez zwykłe HTTP. Serwer widzi HTTP i przekierowuje na HTTPS, a cykl się powtarza. Cloudflare dokumentuje dokładnie tę pętlę dla swojego trybu szyfrowania Flexible.
Czy wyczyszczenie ciasteczek naprawia zbyt wiele przekierowań?
Tylko wtedy, gdy ciasteczko jest częścią pętli, na przykład sesja logowania, która nigdy się nie zapisuje. Jeśli pętla jest w regułach serwera, czyszczenie ciasteczek niczego nie zmienia.
Czy pętla przekierowań może zaszkodzić SEO?
Strona utknięta w pętli nigdy się nie ładuje, więc roboty wyszukiwarek też nie mogą jej odczytać. Naprawiaj pętle szybko i utrzymuj krótkie łańcuchy przekierowań.
Dlaczego pętle powstają na styku warstw
Nowoczesna strona ma często trzy lub cztery miejsca, które mogą przekierowywać: CDN, platformę hostingową, serwer WWW i aplikację. Każde z nich konfiguruje się na osobnym ekranie, więc dwa mogą po cichu nie zgadzać się co do schematu, hosta lub ukośnika na końcu.
Symulator powyżej modeluje właśnie to. Umieść reguły każdej warstwy na jednej liście, a niezgodność zamieni się w widoczny cykl.
Problem schematu za proxy
Gdy TLS kończy się na proxy lub load balancerze, Twój serwer widzi wyłącznie zwykłe HTTP. Reguła mówiąca, by przekierować wszystko z HTTP na HTTPS, odpala się wtedy przy każdym żądaniu, także przy tych, które dla odwiedzającego były HTTPS. Proxy wysyłają oryginalny schemat w nagłówku X-Forwarded-Proto, więc serwer powinien sprawdzać właśnie jego.
Konfiguracja, która przekierowuje dokładnie raz
nginx sam obsługujący TLS
Jeden blok server łapie każde żądanie HTTP i wysyła je prosto na docelowy host.
nginx za proxy, które kończy TLS
Przekierowuj tylko wtedy, gdy oryginalnym schematem odwiedzającego, wysłanym przez proxy w X-Forwarded-Proto, było http.
Zobacz każdy przeskok z wiersza poleceń
-I prosi tylko o nagłówki, -L podąża za przekierowaniami. Każdy blok w wyniku to jeden przeskok.
Symulator pętli przekierowań
Reguły przekierowań, po jednej w linii (from -> to)
Adres początkowy
Przeskoki, za którymi podążyłaby przeglądarka
Pętla: łańcuch wraca do {v}, więc przeglądarka zatrzymuje się z błędem zbyt wielu przekierowań.
Brak pętli: łańcuch kończy się na {v} po {n} przekierowaniach.
Łańcuch przekroczył {n} przeskoków bez końca, więc przeglądarka się poddaje.
Żadna reguła nie pasuje do adresu początkowego, więc ładuje się on bez przekierowania.