ERR_TOO_MANY_REDIRECTS: co powoduje pętlę przekierowań i jak ją naprawić

Co oznacza ERR_TOO_MANY_REDIRECTS

Przekierowanie mówi przeglądarce "strona, której chcesz, jest gdzie indziej, idź tam zamiast tego". Pojedyncze przekierowanie, a nawet dwa czy trzy z rzędu, to normalka: goła domena przekierowująca na www, albo stary URL przekierowujący na swój zamiennik. Pętla zdarza się, gdy URL przekierowuje na drugi URL, który przekierowuje z powrotem na pierwszy, albo na samego siebie. Ponieważ przeglądarka nigdy nie dociera do strony, która faktycznie zwraca treść, ucina łańcuch i pokazuje błąd zamiast wisieć w nieskończoność.

Jak pojawia się błąd

Chrome i Edge pokazują "This page isn't working - redirected you too many times" z kodem błędu ERR_TOO_MANY_REDIRECTS. Firefox pokazuje "The page isn't redirecting properly." Safari mówi "Safari can't open the page because too many redirects occurred."

curl z flagą -L podąża za przekierowaniami tak samo jak przeglądarka, a wypisanie każdego skoku pokazuje dokładnie, gdzie pętla się powtarza:

curl -sIL https://example.com/ | grep -E "^(HTTP|location)"
HTTP/1.1 301 Moved Permanently
location: http://example.com/
HTTP/1.1 301 Moved Permanently
location: https://example.com/
HTTP/1.1 301 Moved Permanently
location: http://example.com/

Ten wzorzec, http na https i z powrotem na http, to najczęstszy kształt tego błędu. curl zatrzymuje się na własnym domyślnym limicie (50 przekierowań), zamiast podążać za nim wiecznie, a powtarzające się linie location czynią pętlę oczywistą bez potrzeby otwierania przeglądarki w ogóle.

Co powoduje pętlę przekierowań

• Niedopasowanie HTTP-do-HTTPS między proxy albo CDN a serwerem źródłowym. To klasyczny przypadek. Jeśli tryb SSL/TLS Cloudflare jest ustawiony na Flexible, Cloudflare terminuje TLS na brzegu i łączy się z serwerem źródłowym po czystym HTTP. Jeśli serwer źródłowy też ma regułę przekierowującą każde żądanie HTTP na HTTPS (częsty domyślny mechanizm bezpieczeństwa), serwer źródłowy odsyła przeglądarkę z powrotem na HTTPS, Cloudflare obniża znów do HTTP przy następnym skoku, i oba ustawienia walczą ze sobą w nieskończoność.
• Reguły www i bez www wskazujące na siebie nawzajem. Jedna reguła przekierowuje gołą domenę na www, a osobna reguła, często dodana później przez innego administratora albo wtyczkę, przekierowuje www z powrotem na gołą domenę.
• Niedopasowanie siteurl albo home WordPressa. Jeśli skonfigurowany URL witryny w bazie danych nie zgadza się z URL-em, którego faktycznie używają odwiedzający (pozostałość po URL-u stagingowym, niedopasowanie schematu po dodaniu SSL), WordPress wciąż przekierowuje w stronę skonfigurowanej wartości.
• Ciasteczka, których serwer oczekuje, ale nigdy nie otrzymuje, albo przekierowanie logowania, które po cichu zawodzi. Strona, która przekierowuje niezalogowanych odwiedzających do kroku logowania, który potem przekierowuje z powrotem na tę samą stronę, bo ciasteczko sesji nigdy nie zostało ustawione (często blokowane przez reguły plików cookie stron trzecich przeglądarki albo brakujący atrybut Secure/SameSite), zapętla się w nieskończoność.
• Konfliktujące reguły ukośnika końcowego albo prefiksu językowego. Jedna reguła dodaje ukośnik końcowy, druga go usuwa; jedna reguła dodaje prefiks językowy na podstawie lokalizacji przeglądarki, druga go usuwa dla kanonicznych URL-i, i obie się nawzajem znoszą.
• Warstwa cache'ująca serwuje nieaktualne przekierowanie. CDN albo reverse proxy zbuforowało stare 301, które wskazywało na URL, który od tamtej pory się zmienił i przekierowuje z powrotem na oryginał.

Jak rozpoznać, kto zawinił

Jeśli pętla zdarza się dla każdego odwiedzającego w każdej sieci, to problem konfiguracji serwera albo CDN, nie coś lokalnego. Jeśli zdarza się tylko Tobie, wyczyść najpierw ciasteczka dla witryny, bo złe albo wygasłe ciasteczko sesji powoduje sporą część pętli dotykających jednego odwiedzającego. Uruchomienie kontroli HTTP z kilku lokalizacji rozstrzyga to w jednym żądaniu: jeśli ten sam łańcuch przekierowań (albo ta sama awaria) pojawia się z każdej lokalizacji, naprawa leży po stronie serwera.

Jak naprawić ERR_TOO_MANY_REDIRECTS

Jeśli jesteś odwiedzającym

1. Wyczyść ciasteczka dla witryny. W Chrome kliknij ikonę kłódki albo suwaka obok paska adresu, otwórz ustawienia witryny i wyczyść ciasteczka oraz dane witryny tylko dla tej domeny.
2. Wypróbuj okno incognito albo prywatne. To wyklucza rozszerzenie przeglądarki albo zapisane ciasteczko jako przyczynę, bez dotykania Twojego zwykłego profilu.
3. Wypróbuj inną sieć, na przykład dane mobilne zamiast Wi-Fi. Niektóre firmowe proxy albo proxy dostawcy internetu przepisują żądania w sposób, który tworzy pętlę tylko w tej sieci.
4. Wyczyść cache przeglądarki na wypadek, gdyby sama odpowiedź przekierowania została zbuforowana sprzed naprawienia witryny.

Jeśli prowadzisz witrynę

1. Sprawdź tryb SSL swojego CDN wobec reguły przekierowania serwera źródłowego. W Cloudflare otwórz SSL/TLS i ustaw tryb na Full albo Full (strict), nie Flexible, zawsze gdy serwer źródłowy przekierowuje HTTP na HTTPS. Full wciąż pozwala serwerowi źródłowemu używać certyfikatu samopodpisanego; Full (strict) wymaga ważnego.
2. Ufaj nagłówkowi przekazanego protokołu zamiast przekierowywać na ślepo. Gdy proxy stoi przed Twoją aplikacją, serwer źródłowy musi przekierowywać na podstawie X-Forwarded-Proto, nie surowego połączenia, które zawsze wygląda jak HTTP z perspektywy zza proxy. Na nginx:

   if ($http_x_forwarded_proto = "http") {
       return 301 https://$host$request_uri;
   }

   i upewnij się, że CDN albo load balancer faktycznie ustawia ten nagłówek przy każdym żądaniu.
3. Sprawdź reguły przekierowań w kolejności, w tym .htaccess, bloki server nginx, middleware na poziomie aplikacji i dowolne reguły stron CDN, pod kątem dwóch reguł wskazujących na siebie nawzajem. Częsty wzorzec Apache, który zapętla się za proxy:

   RewriteCond %{HTTPS} off
   RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

   zawodzi tak samo jak powyższy przypadek nginx, bo %{HTTPS} odczytuje połączenie, które nawiązuje proxy, nie to, które nawiązał odwiedzający; sprawdź zamiast tego %{HTTP:X-Forwarded-Proto}.
4. Napraw URL witryny WordPress, jeśli to dotyczy: w wp-admin > Settings > General potwierdź, że zarówno WordPress Address, jak i Site Address zgadzają się z URL-em, którego faktycznie używają odwiedzający, protokół włącznie. Jeśli sam panel admina jest niedostępny z powodu pętli, ustaw WP_HOME i WP_SITEURL bezpośrednio w wp-config.php.
5. Wybierz jedną kanoniczną formę i przekieruj do niej wszystko inne raz, nie w łańcuchu: www albo bez www, ukośnik końcowy albo bez niego, jedna reguła na decyzję, zamiast kilku reguł nakładanych z czasem przez różne narzędzia.
6. Wyczyść cache CDN po naprawieniu reguły, bo zbuforowane 301 albo 302 wciąż wysyła starą odpowiedź, dopóki nie wygaśnie albo nie zostanie wyczyszczone.

Powiązane błędy

• Kody statusu przekierowań 3xx tłumaczy, co oznaczają 301, 302, 303, 307 i 308.
• 301 kontra 302 obejmuje, kiedy przekierowanie powinno być stałe, a kiedy tymczasowe, co ma znaczenie dla wyszukiwarek i cache'owania, nie tylko dla pętli.

Jak zapobiec ERR_TOO_MANY_REDIRECTS

Pętla przekierowań niemal zawsze jest wprowadzana przez zmianę konfiguracji: nowy CDN, nowy certyfikat SSL, aktualizację wtyczki albo migrację, która dotknęła URL-a witryny. Kontrola HTTP, która obserwuje kod odpowiedzi i podąża za przekierowaniami według harmonogramu, wyłapuje pętlę w chwili jej pojawienia się, z ponad 300 punktów kontrolnych w 158 miastach, zamiast czekać na zgłoszenie wsparcia. HostTracker monitoruje witryny od 2004 roku i może alarmować e-mailem, SMS-em, połączeniem głosowym, przez Slack, Telegram i inne kanały w chwili, gdy kontrola zaczyna zawodzić.

Najczęściej zadawane pytania

Ile przekierowań pozwala przejść przeglądarka, zanim się podda?

Chrome i przeglądarki oparte na Chromium zatrzymują się przy około 20. Domyślny limit curla z -L to 50. Dokładna liczba różni się w zależności od klienta, ale każdy z nich w końcu się zatrzyma, zamiast podążać za pętlą wiecznie.

Dlaczego pętla zaczyna się dopiero po przejściu na Cloudflare (albo inny CDN)?

Niemal zawsze przez tryb SSL/TLS. Tryb Flexible mówi czystym HTTP do serwera źródłowego; jeśli serwer źródłowy nalega na HTTPS, obie strony przekierowują się nawzajem w nieskończoność. Przełączenie na Full albo Full (strict) zwykle naprawia to natychmiast.

Czy rozszerzenie przeglądarki może to spowodować?

Tak, zwłaszcza rozszerzenia wymuszające HTTPS, przepisujące żądania albo zarządzające ciasteczkami. Test w oknie incognito z wyłączonymi rozszerzeniami szybko to wyklucza.

Czy to wpływa na SEO?

Tak. Roboty wyszukiwarek poddają się przy pętli przekierowań tak samo jak przeglądarka, a zapętlony URL nie zostanie zaindeksowany albo wypadnie z indeksu, jeśli wcześniej działał.

Widzę błąd tylko na jednej konkretnej stronie, nie na całej witrynie. Co jest inaczej?

Sprawdź regułę specyficzną dla strony: stronę wymagającą logowania, zbuforowane stare przekierowanie tylko dla tego URL-a, albo niedopasowanie ukośnika końcowego istniejące tylko na tej trasie. Porównaj dokładny łańcuch przekierowań dla tego URL-a z działającą stroną poleceniem curl -sIL.

Czy pojedyncze przekierowanie (jak bez-www na www) to coś, co trzeba naprawić?

Nie, pojedyncze przekierowanie samo w sobie jest normalne i oczekiwane. Problemem, który opisuje ten błąd, jest tylko powtarzający się łańcuch, który nigdy nie dociera do finalnej odpowiedzi 200.