Pętla przekierowań: jak znaleźć i naprawić ERR_TOO_MANY_REDIRECTS

Pętla przekierowań to łańcuch przekierowań HTTP, który nigdy nie ląduje: adres URL A wysyła przeglądarkę do adresu URL B, B odsyła ją z powrotem do A, a po mniej więcej dwudziestu skokach przeglądarka przestaje próbować i wypisuje ERR_TOO_MANY_REDIRECTS. Na stronie docelowej nic nie jest zepsute. Dwie reguły po prostu nie zgadzają się co do tego, gdzie ma znajdować się adres URL, i każda z nich wciąż cofa działanie drugiej.

Zapętlone przekierowanie to jeden z niewielu błędów webowych, który sam wskazuje swoją przyczynę, o ile patrzy się na właściwą rzecz. Nie na przeglądarkę, nie na stronę błędu, i na pewno nie na pamięć podręczną: na łańcuch przekierowań. Każdy skok niesie nagłówek Location, a dwa adresy, które się powtarzają, to dwie reguły, które trzeba pogodzić. Ten wpis przechodzi przez diagnozę w jednej komendzie, przyczyny leżące u podstaw niemal każdej pętli przekierowań, jaką musiałem rozplątać, oraz naprawę, która po cichu nie tworzy drugiej pętli gdzie indziej. Jeśli sama rodzina przekierowań jest niejasna, rodzaje przekierowań URL to mapa; to jest wersja do rozwiązywania problemów.

Co naprawdę oznacza ERR_TOO_MANY_REDIRECTS

Przeglądarki podążają za przekierowaniami w twoim imieniu, ale nie w nieskończoność. Każdy klient utrzymuje budżet skoków i porzuca żądanie, gdy się on wyczerpie: Chrome zatrzymuje się na 20 i nie pozwala tego zmienić, Firefox dostarcza ten sam domyślny limit pod network.http.redirection-limit, a curl pozwala na 50, zanim zacznie protestować. Standard pozostawia tę liczbę otwartą. RFC 9110 mówi jedynie, że klient powinien wykrywać cykliczne przekierowania i na nie reagować, co jest grzecznym sposobem specyfikacji na powiedzenie, że każda przeglądarka potrzebuje bezpiecznika.

To rozróżnienie ma znaczenie dla diagnozy, bo błąd wcale nie dowodzi istnienia cyklu. Łańcuch dwudziestu jeden odrębnych skoków bez powtórzeń wywołuje dokładnie ten sam komunikat co dwa adresy URL odbijające się od siebie w nieskończoność. Oba warto naprawić, ale tylko jeden z nich ma parę adresów do pogodzenia. Materiał referencyjny MDN o przekierowaniach omawia obie postacie, a praktyczna różnica ujawnia się w chwili, gdy wypiszesz łańcuch.

Jeszcze jedna rzecz, którą ukrywa strona błędu: trwałe przekierowanie zostaje zapisane w pamięci podręcznej przeglądarki. Jeśli pętla została zbudowana z odpowiedzi 301, odwiedzający wciąż zapętlają się lokalnie nawet po naprawieniu serwera, dopóki ten wpis w pamięci podręcznej nie wygaśnie albo go nie wyczyszczą. Właśnie ten fakt sprawia, że testuję zmiany przekierowań za pomocą 302 i awansuję do 301 dopiero wtedy, gdy łańcuch jest poprawny - nawyk, za którym w pełni przemawia porównanie przekierowań 301 vs 302.

Prześledź łańcuch przekierowań jedną komendą

Pomiń przeglądarkę. Najszybszym sposobem odczytania dowolnej pętli przekierowań jest terminal, bo curl wypisuje każdy skok zamiast zwijać je w jedną stronę błędu:

curl -sIL https://example.com | grep -E '^HTTP|^[Ll]ocation'

Otrzymujesz linijkę statusu i nagłówek Location dla każdego skoku, po kolei. Przeczytaj to od góry do dołu, a pojawi się jeden z trzech wzorców. Dwa naprzemienne adresy URL oznaczają prawdziwy cykl, a para nazywa obie winne reguły. Długi pochód odrębnych adresów URL oznacza łańcuch, który ktoś nawarstwiał przez lata, przy czym każdy skok jest sam w sobie uzasadniony. A łańcuch, który dobrze rozwiązuje się w terminalu, ale wciąż zawodzi w przeglądarce, oznacza, że pętla jest napędzana ciasteczkami, bo curl domyślnie nie wysyła żadnych ciasteczek.

Ten ostatni przypadek zasługuje na własne sprawdzenie, bo to on sprawia, że ludzie przez całe popołudnie obwiniają swoje DNS:

curl -sIL -c jar.txt -b jar.txt https://example.com/account | grep -E '^HTTP|^[Ll]ocation'

Z dołączonym plikiem ciasteczek pętla logowania albo zgody odtwarza się w wierszu poleceń, gdzie faktycznie widać, który punkt końcowy wciąż ustawia, a potem odrzuca sesję. W przeglądarce odpowiednikiem tego widoku jest panel Network z włączoną opcją "Preserve log", która chroni wcześniejsze skoki przed wyczyszczeniem podczas nawigacji strony. Jeśli wolisz w ogóle nie otwierać terminala, nasz test linków śledzi łańcuch w przeglądarce i wypisuje kod statusu przy każdym skoku.

Przyczyny leżące u podstaw niemal każdej pętli przekierowań

Gdy już widzisz łańcuch, przyczyna zwykle jest jedną z niewielkiej garstki. Powtarzająca się para adresów URL mówi ci, na którą warstwę spojrzeć: schemat przełączający się tam i z powrotem wskazuje na terminację TLS, przełączająca się nazwa hosta wskazuje na regułę kanonicznego hosta, a ścieżka, która na przemian zyskuje i traci ukośnik, wskazuje na kolejność reguł przepisywania.

reguły https za proxy, które kończy TLS

To najpowszechniejsze nieskończone przekierowanie we współczesnym webie, i pojawiło się w chwili, gdy proxy zaczęły kończyć TLS przed origin. Proxy przyjmuje żądanie HTTPS od odwiedzającego, a potem pobiera twój origin przez zwykłe HTTP. Twój origin widzi niezabezpieczone żądanie, robi to, co mu kazano, i przekierowuje do HTTPS. Proxy serwuje to przekierowanie, jest pytane ponownie, znów pobiera origin przez HTTP, i tak w kółko. Cloudflare dokumentuje dokładnie tę awarię w swoim trybie szyfrowania elastycznego, a każde inne proxy ma tę samą pułapkę pod inną nazwą.

Są dwie czyste naprawy. Przełącz proxy na pełny tryb szyfrowania, żeby rozmawiało z twoim origin przez TLS, co jest poprawną odpowiedzią niemal w każdym przypadku. Albo, jeśli skok do origin naprawdę musi zostać zwykły, spraw, by reguła origin odczytywała nagłówek X-Forwarded-Proto zamiast surowego połączenia, żeby przestała przekierowywać żądania, które były już bezpieczne na brzegu sieci.

www i apex nie zgadzają się, który host wygrywa

Jedna reguła kanonicznego hosta jest w porządku. Dwie, napisane w różnym czasie przez różne osoby, to pętla. Klasyczna wersja ma konfigurację serwera wysyłającą apex do www, podczas gdy konfiguracja aplikacji odsyła www z powrotem do apex, i obie są pewne, że mają rację. Zobaczysz to natychmiast w łańcuchu: example.com do www.example.com do example.com, w nieskończoność.

Wybierz jeden host, wymuszaj go dokładnie w jednym miejscu i usuń drugą regułę, zamiast próbować doprowadzić je do zgody. To samo dotyczy przepisywania końcowego ukośnika albo wielkości liter: gdy dwie reguły normalizują ten sam adres URL w przeciwnych kierunkach, dostajesz cykl przekierowań, mimo że każda reguła z osobna jest rozsądna.

ustawienie adresu URL CMS-a albo aplikacji, które już nie pasuje

Większość aplikacji przechowuje własny kanoniczny adres, a to pole jest regułą przekierowania z przyjazną nazwą. Zmień domenę, przenieś się do nowego środowiska albo przywróć zrzut bazy danych z innego hosta, a aplikacja zaczyna przekierowywać każde żądanie na adres, który przekierowuje z powrotem. Ponieważ ustawienie żyje w bazie danych, a nie w konfiguracji serwera www, przetrwa audyt konfiguracji, który właśnie zrobiłeś, co sprawia, że jest tak irytujące do znalezienia.

Sygnaturą jest łańcuch, który opuszcza twoją bieżącą nazwę hosta i nigdy do niej nie wraca. Popraw zapisany adres na domenę, którą faktycznie obsługujesz, a potem wyczyść wszelką pamięć podręczną aplikacji albo strony, która przechwyciła zły adres.

pętle ciasteczek i sesji dotyczące tylko zalogowanych użytkowników

Tutaj reguły są niewinne, a problemem jest stan. Bramka przekierowuje niezalogowanych odwiedzających na stronę logowania, strona logowania przekierowuje zalogowanych z powrotem, a ciasteczko sesji, którego nie da się odczytać na docelowej domenie, zostawia obie strony przekonane, że to druga powinna się tym zająć. Banery zgody powodują ten sam kształt problemu, gdy przekierowanie ustawiające ciasteczko zgody samo zostaje zablokowane.

Wskazówka jest ta sama co w poprzedniej sekcji: czyste okno prywatne działa, albo curl bez pliku ciasteczek rozwiązuje się normalnie. Sprawdź zakres domeny i Path ciasteczka, jego atrybuty Secure i SameSite w zestawieniu ze schematem, który faktycznie obsługujesz, oraz czy jest ustawiane na apex, a odczytywane na www.

Pętle przekierowań rzadko są tajemnicze, gdy łańcuch jest już na ekranie, ale potrafią pochłonąć całe popołudnie, jeśli zgadujesz zamiast śledzić. Jeśli wolisz mieć kontrolę nad warstwą przekierowań, zamiast się z nią spierać, darmowy plan Elido daje ci linki, których cel jest pojedynczą zapisaną wartością, którą możesz przekierować na nowo, z każdym skokiem zalogowanym.

Napraw to, nie tworząc drugiej pętli

Sama naprawa jest krótka, a kolejność liczy się bardziej niż składnia. Zmień jedną regułę, a potem prześledź ponownie. Zmiana trzech i przeładowanie strony nic ci nie mówi o tym, która miała znaczenie, a widziałem zespół, który w ten sposób stracił godzinę na pętli spowodowanej regułą, którą już naprawili przy pierwszej próbie.

1. Usuń albo odwróć dokładnie jedną z dwóch reguł nazwanych przez łańcuch, tak żeby żądanie mogło osiągnąć 200 w jednym skoku.
2. Uruchom ponownie śledzenie curl -sIL i potwierdź, że łańcuch to teraz co najwyżej jedno przekierowanie, bez powtórzonej nazwy hosta.
3. Wyczyść pamięć podręczną przeglądarki albo testuj w oknie prywatnym, bo każde 301, które wcześniej zserwowałeś, wciąż jest zapisane lokalnie w pamięci podręcznej i upozoruje awarię, której już nie ma.
4. Dopiero wtedy awansuj tymczasowe przekierowania na trwałe, gdy kształt łańcucha jest już ustalony.

Na końcu tej listy czekają dwie pułapki. Jedną jest HSTS: gdy host raz wyśle nagłówek Strict-Transport-Security, przeglądarki same z siebie podnoszą każde żądanie do HTTPS, więc reguła origin, która też wymusza HTTPS, staje się zbędna i może zamienić błędną konfigurację proxy w pętlę, której nie odtworzysz bez wyczyszczenia wpisu HSTS. Drugą jest pamięć podręczna stojąca przed pętlą. CDN, które zapisało 301 w pamięci podręcznej, chętnie będzie je nadal serwować, nawet gdy origin przestanie je wysyłać, dlatego wyczyszczenie pamięci podręcznej należy do naprawy, a nie do etapu po niej. Długie łańcuchy, które nigdy się nie zapętlają, też warto skrócić przy tej samej okazji: każdy dodatkowy skok to kolejna okazja, żeby zgubić ciąg zapytania, co jest dokładnie sposobem, w jaki parametry UTM znikają w GA4, i częścią powodu, dla którego krótkie linki nie muszą szkodzić SEO, o ile pozostają jednym skokiem w głąb.

Gdy pętla dotyczy krótkiego linku

Krótkie linki dodają jeszcze jedno miejsce, w którym może powstać cykl, i nie jest to przekierowanie samego skracacza. Krótki link to pojedynczy zapisany skok: slug wchodzi, cel wychodzi. Pętla pojawia się, gdy cel wskazuje z powrotem, co zdarza się częściej, niż mogłoby się wydawać. Ktoś edytuje link kampanii tak, by wskazywał na landing page, landing page ma starą regułę przekierowującą do krótkiego adresu URL, bo to był kanoniczny adres do udostępniania w zeszłym kwartale, i teraz oba się odbijają. Oba skoki zachowują się dokładnie tak, jak zostały skonfigurowane.

W tym samym łańcuchu pojawiają się jeszcze dwa warianty. Jednym jest para krótkich linków wskazujących na siebie nawzajem po zbiorczej edycji, zwykle po imporcie z arkusza kalkulacyjnego, gdzie kolumna celu zawierała krótkie adresy URL zamiast końcowych. Drugim jest własna domena wciąż rozwiązująca się do hosta, który przekierowuje z powrotem do skracacza, co jest pozostałością po DNS, a nie problemem linku, a własne domeny dla krótkich linków opisują, jak powinny wyglądać rekordy. We wszystkich trzech przypadkach naprawą jest ustawienie celu na stronę końcową, a nie na kolejne przekierowanie, co możesz zrobić, nie dotykając niczego, co już zostało wydrukowane albo opublikowane.

Ponieważ cel jest zapisany, a nie zaszyty w adresie URL, żadna z tych sytuacji nie wymaga ponownego druku. To cały argument za zarządzanymi linkami, a krótki link nie działa to szerszy przewodnik po diagnozie, gdy objaw nie jest konkretnie pętlą.

Nie dopuść, żeby wystąpiła następna

Pętle przekierowań to błąd dryfu konfiguracji, więc trwałe naprawy są tymi nudnymi. Trzymaj decyzję o kanonicznym hoście w jednym miejscu i traktuj każdą drugą regułę dotykającą schematu albo nazwy hosta jako błąd od razu, gdy ją zobaczysz. Śledź nowe przekierowania za pomocą curl -sIL, zanim je ogłosisz, a nie po tym, jak ktoś zgłosi pustą stronę. Jeśli linki mają znaczenie dla przychodu, załóż na nie kontrolę: zaplanowane śledzenie, które zawodzi, gdy łańcuch rośnie ponad jeden skok, wyłapuje dryf na długo przed klientem, a monitorowanie przekierowań linków pokazuje, jak to wygląda podłączone do prawdziwego alertowania.

Szerszym nawykiem jest traktowanie celów jako danych, które można audytować. Zapobieganie rozpadowi linków opisuje tę samą dyscyplinę dla linków, które po cichu przestają się rozwiązywać, i tak czy inaczej to ta sama cotygodniowa kontrola. Szczerze mówiąc, większość widzianych przeze mnie pętli powstała przez dwie kompetentne osoby, które każda naprawiła ten sam problem w innej warstwie, miesiąc od siebie. Zapisz regułę raz, a pętla przestaje być możliwa.

Przeczytaj serię cornerstone

Ten wpis należy do klastra inżynieryjnego. Kształt samej ścieżki przekierowania opisuje osiąganie p95 poniżej 15ms dla przekierowań, a to, który kod statusu pasuje gdzie, zanim zaczniesz nawarstwiać reguły, opisują rodzaje przekierowań URL.

Powiązane wpisy na blogu

• Rodzaje przekierowań URL: 301, 302, 307, 308 i inne
• Przekierowania 301 vs 302: którego powinny używać krótkie linki
• Krótki link nie działa? Zdiagnozuj to jedną komendą
• Własne domeny dla krótkich linków: DNS, TLS i brzeg sieci
• Podatności typu open redirect i jak im zapobiegać
• Monitorowanie krótkich linków za pomocą Sentry i Datadog