Pętla przekierowań to sytuacja, w której adres odsyła do kolejnego, a ten prędzej czy później wraca do punktu wyjścia. Przeglądarka krąży wtedy w kółko, aż uzna, że dalsze próby nie mają sensu, i pokazuje komunikat ERR_TOO_MANY_REDIRECTS. Strona w takim stanie nie ładuje się dla nikogo, więc nie jest to usterka kosmetyczna, tylko całkowita niedostępność adresu.
Skrót: przeglądarki przerywają wędrówkę po około 20 przekierowaniach, a Safari po 16. Robot wyszukiwarki podąża najwyżej za 10 skokami, przy czym Google zaleca, żeby łańcuch nie przekraczał 3, a w żadnym razie 5. Najczęstszą przyczyną pętli jest konflikt dwóch reguł ustawionych niezależnie od siebie: jedna wymusza szyfrowanie, druga wersję adresu z www albo bez.
Co dokładnie zgłasza przeglądarka
Komunikat wygląda inaczej w każdej przeglądarce, ale oznacza to samo. Chrome pokazuje ERR_TOO_MANY_REDIRECTS, Firefox informuje, że strona nie przekierowuje prawidłowo, a Safari mówi o zbyt wielu przekierowaniach. Za każdym razem chodzi o przekroczenie wewnętrznego limitu skoków.
Sama specyfikacja HTTP nie narzuca żadnej konkretnej liczby, więc każdy klient ustala własny próg. W praktyce Firefox trzyma parametr o nazwie network.http.redirection-limit z wartością domyślną 20, Chrome zachowuje się podobnie, a Safari przerywa wcześniej, po około 16 skokach. Narzędzia wiersza poleceń mają własne progi: curl po przekroczeniu limitu kończy pracę kodem wyjścia 47.
Z punktu widzenia użytkownika liczy się jeden wniosek. Skoro przeglądarki różnią się progami, ta sama pętla może objawiać się u różnych osób w różnym momencie, a przy krótkim łańcuchu bywa, że jedna przeglądarka jeszcze stronę otworzy, a druga już nie.
Ile przekierowań wytrzymuje przeglądarka, a ile robot wyszukiwarki
Limity robota są znacznie ostrzejsze niż limity przeglądarki i to one decydują o widoczności strony. Google podaje, że jego robot podąża najwyżej za 10 skokami w łańcuchu, ale jednocześnie odradza zbliżanie się do tej granicy.
| Klient | Limit skoków | Co się dzieje po przekroczeniu |
|---|---|---|
| Chrome | około 20 | komunikat ERR_TOO_MANY_REDIRECTS zamiast strony |
| Firefox | 20 domyślnie | informacja o nieprawidłowym przekierowaniu |
| Safari | około 16 | komunikat o zbyt wielu przekierowaniach |
| Robot Google | 10 | adres nie zostaje zaindeksowany |
| curl | własny próg | zakończenie pracy kodem 47 |
Zalecenie Google idzie dalej niż sam limit techniczny: łańcuch nie powinien przekraczać 3 skoków, a granicą, której lepiej nie dotykać, jest 5. Powód jest praktyczny i policzalny, co rozłożyłem na czynniki w tekście o tym, ile kosztuje łańcuch przekierowań. Każdy skok to osobne zapytanie do serwera, więc trasa wydłuża czas ładowania, a przy okazji rośnie ryzyko, że któryś element łańcucha przestanie działać po kolejnej zmianie konfiguracji.
Konflikt reguł www i szyfrowania, czyli najczęstsza przyczyna
Typowa pętla powstaje wtedy, gdy dwie reguły ustawione w różnych miejscach mają sprzeczne oczekiwania. Pierwsza wymusza wersję szyfrowaną adresu, druga wymusza wersję bez www. Jeśli obie działają na różnych poziomach i nie uwzględniają się nawzajem, powstaje ping pong, w którym każda odsyła do adresu natychmiast łamiącego warunek drugiej.
Rozpoznasz to po tym, że łańcuch skacze między dwoma wariantami tego samego adresu. Kolejne kroki wyglądają jak powtarzająca się para, na przykład wersja bez www prowadzi do wersji z www, a ta natychmiast wraca do poprzedniej. Charakterystyczne jest to, że pętla ma zawsze tę samą długość cyklu, bo powtarza dokładnie ten sam schemat.
Pętla po włączeniu certyfikatu przez panel hostingu
Druga częsta odmiana pojawia się po włączeniu szyfrowania przez zewnętrzną usługę pośredniczącą w ruchu. Usługa przyjmuje połączenie szyfrowane od użytkownika, ale do serwera docelowego łączy się już bez szyfrowania. Serwer widzi połączenie nieszyfrowane, więc zgodnie ze swoją regułą odsyła użytkownika na wersję szyfrowaną, a ta trafia z powrotem do usługi pośredniczącej.
Objaw bywa wtedy mylący, bo w panelu wszystko wygląda poprawnie i certyfikat jest aktywny. Rozwiązaniem jest ustawienie trybu, w którym połączenie między usługą a serwerem również jest szyfrowane, albo zdjęcie reguły wymuszającej szyfrowanie po stronie serwera, żeby decyzja zapadała tylko w jednym miejscu.
Pętla w WordPressie: adres witryny i wtyczki
W WordPressie do gry wchodzi dodatkowy element, czyli adres witryny zapisany w bazie danych. Jeśli w ustawieniach zapisana jest wersja bez www, a serwer wymusza wersję z www, każde wejście uruchamia dwa sprzeczne przekierowania. To samo dzieje się po zmianie domeny, gdy w bazie zostaje stary adres.
Drugim źródłem są wtyczki działające równolegle z regułami serwera. Wtyczka wymuszająca szyfrowanie, wtyczka do przekierowań, wtyczka wielojęzyczności i moduł SEO potrafią dodać własne reguły, nie wiedząc o sobie nawzajem. Diagnostyka polega wtedy na wyłączaniu ich po kolei i sprawdzaniu, po którym wyłączeniu pętla znika.
Warunkiem sensownej diagnostyki jest sprawdzanie efektu z zewnątrz, a nie w panelu. Panel często pokazuje regułę zadeklarowaną, a nie trasę faktycznie pokonywaną przez przeglądarkę, i właśnie ta różnica utrudnia znalezienie przyczyny.
Pętla widoczna tylko na jednym urządzeniu
Zdarza się wariant, w którym strona działa u wszystkich poza jedną osobą. Wtedy zwykle winne są ciasteczka albo dane sesji zapisane w przeglądarce. Mechanizm logowania odsyła użytkownika na stronę logowania, ta rozpoznaje nieaktualne dane sesji i odsyła z powrotem, a cykl się zapętla.
Sprawdzenie zajmuje chwilę: wystarczy otworzyć adres w oknie prywatnym albo w innej przeglądarce. Jeśli tam strona działa, przyczyna leży po stronie danych zapisanych lokalnie, a nie w konfiguracji serwera. Czyszczenie ciasteczek dla tej jednej domeny rozwiązuje sprawę bez ruszania czegokolwiek na serwerze.
Jak zdiagnozować pętlę przekierowań
Diagnostyka sprowadza się do zobaczenia całej trasy, a nie tylko jej końca. Przeglądarka pokazuje wyłącznie komunikat o błędzie, więc informacja o tym, które adresy się powtarzają, przepada.
Najszybszą drogą jest przepuszczenie adresu przez narzędzie do sprawdzania przekierowań i statusów HTTP, które wypisuje każdy skok osobno i sygnalizuje moment, w którym adres zaczyna się powtarzać. Przy okazji dobrze jest wrzucić od razu kilka wariantów tego samego adresu: z www i bez, szyfrowany i nieszyfrowany, ze skośnikiem na końcu i bez niego. Porównanie czterech wyników zwykle od razu pokazuje, która para reguł się gryzie.
Drugim krokiem jest ustalenie, gdzie reguła powstaje. Kolejność sprawdzania od zewnątrz do środka oszczędza czas: najpierw usługa pośrednicząca w ruchu, potem konfiguracja serwera, następnie ustawienia systemu zarządzania treścią, na końcu wtyczki.
Jak naprawić pętlę bez psucia reszty serwisu
Zasada porządkująca jest jedna: każdy wymóg powinien być realizowany dokładnie w jednym miejscu. Jeśli szyfrowanie wymusza serwer, wtyczka nie powinna robić tego samego. Jeśli wersję z www wybiera konfiguracja serwera, ustawienia systemu zarządzania treścią muszą się z nią zgadzać.
Praktyczna kolejność działań wygląda tak. Najpierw wyłącz wszystkie reguły przekierowań poza jedną, żeby strona w ogóle wróciła do działania. Potem ustal docelową wersję adresu i zapisz ją w ustawieniach systemu zarządzania treścią. Następnie dodawaj reguły pojedynczo, sprawdzając trasę po każdej zmianie. Na koniec zweryfikuj, czy adres startowy dociera do celu jednym skokiem, a nie serią.
Do trwałych zmian używaj wyłącznie przekierowania 301. Kod tymczasowy w takim miejscu wprowadza wyszukiwarkę w błąd, o czym szerzej w tekście o tym, jak kod 302 wpływa na pozycjonowanie.
Co pętla przekierowań robi z widocznością w wyszukiwarce
Robot wyszukiwarki traktuje pętlę tak samo jak przeglądarka, czyli po kilku skokach rezygnuje. Nie dostaje żadnej treści, więc nie ma czego zaindeksować i adres wypada z wyników. Przy dłużej trwającej awarii dotyczy to nie tylko nowych adresów, ale też tych, które wcześniej miały pozycje.
Osobnym problemem jest sytuacja, w której pętla dotyczy tylko części serwisu, na przykład jednej kategorii. Wtedy spadek jest stopniowy i łatwo przypisać go czemuś innemu, bo strona główna działa bez zarzutu. Dlatego po każdej zmianie w regułach przekierowań sensownie jest sprawdzić nie tylko stronę główną, ale też próbkę podstron z różnych sekcji.
Po naprawie zostaje jeszcze potwierdzenie, że strona docelowa wskazuje sama na siebie w adresie kanonicznym. Zdarza się, że po uporządkowaniu reguł zostaje wskazanie na wariant adresu, którego już nie używasz, a to potrafi utrzymywać zamieszanie w indeksie mimo poprawnie działających przekierowań.
Najczęstsze pytania
Co oznacza komunikat ERR_TOO_MANY_REDIRECTS?
Przeglądarka przekroczyła własny limit przekierowań, bo adresy odsyłały do siebie nawzajem bez dotarcia do treści. Chrome i Firefox przerywają po około 20 skokach, Safari po 16. Komunikat nie mówi nic o przyczynie, wskazuje wyłącznie na to, że trasa nie ma końca.
Czy pętla przekierowań szkodzi pozycjom w wyszukiwarce?
Tak, i to bezpośrednio. Robot nie dociera do treści, więc nie ma czego zaindeksować, a adres wypada z wyników. Robot Google podąża najwyżej za 10 skokami, czyli rezygnuje szybciej niż przeglądarka.
Dlaczego strona działa u mnie, a u klienta nie?
Najczęściej odpowiadają za to ciasteczka i dane sesji zapisane w konkretnej przeglądarce. Sprawdź adres w oknie prywatnym: jeśli tam się otwiera, przyczyna jest lokalna, a nie serwerowa. Drugą możliwością są różne progi limitów, bo Safari przerywa wcześniej niż pozostałe przeglądarki.
Ile przekierowań w łańcuchu jest bezpieczne?
Google zaleca, żeby łańcuch nie przekraczał 3 skoków, a granicą, do której nie należy się zbliżać, jest 5. Docelowo adres startowy powinien prowadzić do celu jednym skokiem, bo każde dodatkowe przekierowanie wydłuża ładowanie i zwiększa ryzyko awarii.
Jak sprawdzić, gdzie dokładnie zapętla się adres?
Potrzebne jest narzędzie pokazujące każdy skok osobno, bo przeglądarka wyświetla wyłącznie komunikat końcowy. Wrzuć od razu kilka wariantów adresu: z www i bez, szyfrowany i nieszyfrowany, ze skośnikiem na końcu i bez. Powtarzająca się para adresów wskazuje parę reguł, które się wykluczają.
Czy wyłączenie wtyczki wystarczy do naprawy?
Czasem tak, ale wtyczka bywa tylko jedną stroną konfliktu. Jeśli druga reguła siedzi w konfiguracji serwera albo w adresie witryny zapisanym w bazie, po ponownym włączeniu wtyczki problem wróci. Trwałe rozwiązanie polega na tym, żeby każdy wymóg realizowało dokładnie jedno miejsce.
