Błąd ERR_TOO_MANY_REDIRECTS - skąd się bierze i jak naprawić pętlę przekierowań?

Data publikacji: 9 października 2026

Otwierasz stronę internetową, ale zamiast jej zawartości widzisz komunikat ERR_TOO_MANY_REDIRECTS. W innych przeglądarkach może pojawić się informacja, że strona przekierowuje zbyt wiele razy albo że przekierowanie nigdy się nie zakończy. Problem często występuje po zmianie domeny, włączeniu HTTPS, uruchomieniu Cloudflare lub zmianie konfiguracji hostingu.

Ten błąd nie oznacza, że serwer przestał odpowiadać. Wręcz przeciwnie: serwer lub kilka usług pośredniczących zwykle odsyła przeglądarkę do kolejnych adresów. Kłopot polega na tym, że użytkownik nigdy nie dociera do właściwej strony. Zamiast tego wraca do adresu, który odwiedził już wcześniej, albo przechodzi przez zbyt długi łańcuch przekierowań.

Naprawa nie powinna polegać na losowym wyłączaniu HTTPS i usuwaniu wszystkich reguł. Najpierw trzeba ustalić, które adresy przekierowują między sobą i w którym miejscu skonfigurowano sprzeczne zasady.

Kluczowe wnioski

• ERR_TOO_MANY_REDIRECTS oznacza, że przeglądarka przerwała serię przekierowań. Nie jest to kod odpowiedzi HTTP, taki jak 404 czy 502.
• Najczęstszą przyczyną jest konflikt reguł dotyczących http i https, wariantów z www i bez www, ustawień aplikacji albo serwera proxy.
• Użytkownik może sprawdzić stronę w trybie prywatnym, wyczyścić dane tylko tej witryny i porównać działanie z inną przeglądarką.
• Administrator powinien prześledzić nagłówki Location, ustawienia WordPressa, serwera WWW i ewentualnego CDN.
• Po naprawie warto przetestować różne warianty adresu, logowanie i najważniejsze podstrony oraz uruchomić monitoring dostępności.

Co oznacza ERR_TOO_MANY_REDIRECTS?

Przekierowanie to instrukcja, dzięki której przeglądarka przechodzi spod jednego adresu URL na inny. Jest potrzebne na przykład wtedy, gdy stary artykuł otrzymuje nowy adres, domena przechodzi z HTTP na HTTPS albo serwis chce obsługiwać tylko jeden wariant nazwy — z www lub bez niego.

Przekierowanie HTTP zwykle wykorzystuje kod z grupy 3xx, taki jak 301, 302, 307 lub 308, oraz nagłówek Location. Dla przeglądarki jest to sygnał: „zasób znajduje się pod innym adresem, wyślij tam kolejne żądanie”.

Prawidłowa sytuacja wygląda na przykład tak:

http://example.com/
  -> 301 https://example.com/
  -> 200 OK

Po jednym przekierowaniu użytkownik otrzymuje właściwą stronę. Problem pojawia się, gdy reguły przeczą sobie nawzajem:

https://example.com/
  -> 301 https://www.example.com/
  -> 301 https://example.com/
  -> 301 https://www.example.com/
  -> ...

Przeglądarka rozpoznaje taką sytuację i przerywa ładowanie. Może też zatrzymać bardzo długi łańcuch przekierowań, nawet jeśli adresy nie powtarzają się dokładnie w tej samej kolejności. Wyświetlany komunikat jest więc skutkiem zabezpieczenia przeglądarki przed nieskończonym przechodzeniem między adresami.

Warto odróżnić ten problem od błędu 502 Bad Gateway. Przy 502 pośrednik nie uzyskuje prawidłowej odpowiedzi od kolejnego serwera. Przy ERR_TOO_MANY_REDIRECTS odpowiedzi mogą być technicznie poprawnymi przekierowaniami, ale ich sekwencja uniemożliwia otwarcie strony.

Najczęstsze przyczyny pętli przekierowań

Konflikt między HTTP a HTTPS

Jedna warstwa infrastruktury przekierowuje użytkownika z http:// na https://, a inna wykonuje przekierowanie w przeciwnym kierunku. Jeśli obie reguły są aktywne, strona przełącza się między dwoma wersjami adresu.

Przyczyną może być ustawienie serwera WWW, reguła w panelu hostingu, opcja w sieci CDN albo logika samej aplikacji. Problem często ujawnia się po włączeniu certyfikatu lub przeniesieniu obsługi HTTPS z serwera aplikacji na reverse proxy.

Sprzeczne reguły dotyczące www

Jeden mechanizm wymusza www.example.com, podczas gdy drugi wymusza example.com. Każdy działa zgodnie z własną konfiguracją, ale razem tworzą pętlę. Dlatego warto wybrać jeden adres kanoniczny i konsekwentnie stosować go w serwerze, aplikacji oraz regułach CDN.

Nieprawidłowe ustawienia adresu w WordPressie

WordPress przechowuje adres instalacji i adres widocznej witryny. Po migracji domeny lub uruchomieniu HTTPS ustawienia te mogą nie odpowiadać rzeczywistej konfiguracji. Dodatkowy problem pojawia się, gdy wtyczka SSL lub przekierowań próbuje poprawiać adres, który serwer już zmienia.

Nie należy automatycznie zakładać, że oba adresy w WordPressie muszą być identyczne. Przy instalacji systemu w osobnym podkatalogu mogą się prawidłowo różnić. Ważne, aby odpowiadały zamierzonemu układowi strony.

Reverse proxy błędnie rozpoznaje protokół

W wielu serwisach połączenie HTTPS kończy się na load balancerze, CDN lub reverse proxy. Dalej żądanie jest przekazywane do aplikacji przez HTTP. Jeżeli aplikacja nie wie, że użytkownik połączył się zewnętrznie przez HTTPS, może próbować ponownie wymuszać HTTPS przy każdym żądaniu.

Taka pomyłka może wystąpić w aplikacjach PHP, Node.js, WordPressie i innych systemach. Istotne jest poprawne przekazanie informacji o oryginalnym protokole, np. przez X-Forwarded-Proto, oraz skonfigurowanie aplikacji tak, by ufała temu nagłówkowi wyłącznie od zaufanego pośrednika.

Przekierowania zależne od logowania lub ciasteczek

Czasem pętla dotyczy tylko panelu klienta. Aplikacja kieruje niezalogowanego użytkownika do formularza logowania, ale po otwarciu formularza odsyła go z powrotem do panelu. Przyczyną może być błędna obsługa sesji, domeny ciasteczka, ustawienia Secure i SameSite albo źle zapamiętany adres powrotu.

To jeden z powodów, dla których problem potrafi występować tylko na konkretnym urządzeniu lub na jednym koncie, mimo że strona główna działa prawidłowo.

Co zrobić, jeśli jesteś zwykłym użytkownikiem?

Zacznij od ustalenia, czy problem dotyczy tylko Twojej przeglądarki, czy całej strony. Nie potrzebujesz do tego dostępu do serwera.

1. Otwórz stronę w oknie prywatnym. Jeśli zaczyna działać, przyczyną mogą być lokalne ciasteczka, zapamiętana sesja albo dane witryny.
2. Sprawdź inną przeglądarkę. Dzięki temu ustalisz, czy problem wiąże się z ustawieniami konkretnego programu lub jego rozszerzeniami.
3. Usuń ciasteczka i dane wyłącznie problematycznej witryny. Nie ma potrzeby od razu usuwać historii wszystkich stron i zapisanych haseł. Pamiętaj, że wyczyszczenie danych może spowodować wylogowanie.
4. Wyłącz na chwilę rozszerzenia, VPN lub ręcznie ustawione proxy, jeśli zmieniają adresy, nagłówki lub sposób kierowania ruchu.
5. Spróbuj otworzyć stronę w innej sieci, np. przez internet mobilny.

Możesz także sprawdzić, czy strona działa z zewnątrz. Taki test pomoże porównać sytuację, ale nie zawsze wykryje pętlę przekierowań: znaczenie ma to, czy narzędzie podąża za przekierowaniami i jaki adres faktycznie sprawdza.

Jeśli problem powtarza się na różnych urządzeniach i sieciach, a szczególnie jeśli pojawił się po zmianach na stronie, najprawdopodobniej wymaga naprawy po stronie właściciela witryny. Warto przekazać mu dokładny adres, godzinę wystąpienia błędu oraz informację, czy kłopot dotyczy całego serwisu, czy tylko logowania.

Jak sprawdzić, dokąd strona przekierowuje?

Dla administratora najważniejsze jest zobaczenie pełnej sekwencji adresów. Można zrobić to za pomocą narzędzi deweloperskich przeglądarki lub programu curl.

Sprawdź nagłówki w terminalu

Na początek wyślij jedno żądanie bez podążania za przekierowaniami:

curl -sS -D - -o /dev/null https://example.com/

Polecenie pobiera odpowiedź i wypisuje jej nagłówki. Jeśli serwer zwróci przekierowanie, zobaczysz kod 301, 302, 307 lub 308 i nagłówek Location, na przykład:

HTTP/2 301
location: https://www.example.com/

W kolejnym kroku prześledź łańcuch przekierowań:

curl -sS -L -D - -o /dev/null --max-redirs 10 https://example.com/

Opcja -L każe przechodzić pod następne adresy. --max-redirs 10 ogranicza liczbę przekierowań, aby test nie trwał bez końca. Gdy limit zostanie przekroczony, curl zakończy polecenie błędem. Przeanalizuj kolejne wartości Location — często od razu widać, czy problem dotyczy HTTPS, www czy ścieżki logowania.

Do diagnostyki używamy tutaj metody GET. Niektóre aplikacje obsługują metodę HEAD inaczej, dlatego test oparty wyłącznie na curl -I nie zawsze odzwierciedla zachowanie zwykłej przeglądarki.

Sprawdź kartę Network w przeglądarce

Otwórz narzędzia deweloperskie (zwykle F12), przejdź do zakładki Network i włącz zachowywanie dziennika po przejściu na inny adres, jeśli przeglądarka ma taką opcję. Następnie odtwórz problem.

Szukaj kolejnych żądań dokumentu i odpowiedzi 3xx. Zwróć uwagę na Location, adres początkowy, różnice między http i https oraz zmianę nazwy hosta. Jeżeli w nagłówkach HTTP nie widać całej pętli, sprawdź też przekierowania wykonywane przez JavaScript albo znacznik HTML meta refresh.

Ważne: nie udostępniaj publicznie pełnego zrzutu z zakładki Network bez sprawdzenia, czy nie zawiera tokenów, ciasteczek sesyjnych lub danych użytkowników.

ERR_TOO_MANY_REDIRECTS w WordPressie — co sprawdzić?

Jeśli problem dotyczy WordPressa, zacznij od ostatnich zmian. Czy właśnie włączyłeś certyfikat SSL, zmieniłeś domenę, przeniosłeś stronę lub zainstalowałeś wtyczkę przekierowań? Taki związek czasowy często wskazuje winowajcę.

Otwórz Ustawienia → Ogólne i zweryfikuj pola „Adres WordPressa (URL)” oraz „Adres witryny (URL)”. Sprawdź protokół, domenę, wariant www i ewentualny podkatalog. Jeżeli panel nie jest dostępny, ustawienia można kontrolować także przez konfigurację wp-config.php lub bazę danych, ale najpierw wykonaj kopię zapasową.

Następnie przejrzyj:

• wtyczki odpowiedzialne za SSL, przekierowania, bezpieczeństwo i cache,
• reguły w pliku .htaccess, jeśli serwer korzysta z Apache,
• przekierowania ustawione w panelu hostingu lub CDN,
• sposób, w jaki WordPress rozpoznaje HTTPS za reverse proxy,
• ustawienia ciasteczek i sesji, jeśli problem dotyczy tylko logowania.

Załóżmy, że WordPress pracuje za proxy, które przyjmuje HTTPS od użytkownika, ale łączy się z aplikacją po HTTP. Jeżeli WordPress nie zna protokołu oryginalnego żądania, może wielokrotnie próbować przejść na HTTPS. Dokumentacja WordPressa opisuje ten problem w kontekście reverse proxy. Naprawa polega na spójnym skonfigurowaniu proxy i aplikacji, a nie na wyłączeniu zabezpieczeń.

Jeśli masz dostęp do serwera, porównaj odpowiedź bezpośrednio z aplikacji z odpowiedzią przez publiczny adres. Pozwoli to oddzielić reguły WordPressa od konfiguracji pośrednika. Przy zmianach produkcyjnych zachowaj możliwość wycofania modyfikacji i nie usuwaj na ślepo wszystkich reguł przepisywania adresów.

Więcej ogólnych wskazówek dotyczących diagnostyki znajdziesz w poradniku jak naprawić niedziałającą stronę na WordPressie.

Pętla przekierowań w Cloudflare

Cloudflare może obsługiwać HTTPS od przeglądarki i łączyć się z Twoim serwerem w innym trybie. To wygodne rozwiązanie, ale jego konfiguracja musi być zgodna z ustawieniami serwera źródłowego.

Klasyczny przykład dotyczy trybu Flexible. Użytkownik otwiera https://example.com, lecz Cloudflare komunikuje się z serwerem źródłowym przez HTTP. Jeżeli ten serwer ma regułę wymuszającą HTTPS, odsyła żądanie z powrotem na https://example.com. Przy następnej próbie sytuacja się powtarza i powstaje pętla.

Jeśli serwer źródłowy obsługuje HTTPS i posiada poprawnie skonfigurowany certyfikat, rozwiązaniem jest zwykle przejście na tryb Full (strict). Weryfikuje on również certyfikat serwera źródłowego. Nie zmieniaj jednak trybu na chybił trafił: serwer bez działającej obsługi TLS albo z błędnym certyfikatem może po takiej zmianie zacząć zwracać inny błąd.

Sprawdź również ustawienia Always Use HTTPS, reguły przekierowań i przekierowania na serwerze źródłowym. Samo włączenie Always Use HTTPS nie jest automatycznie błędem; pętla powstaje wtedy, gdy inna warstwa wymusza sprzeczny adres lub protokół.

Szczegółowe przypadki opisuje dokumentacja Cloudflare dotycząca ERR_TOO_MANY_REDIRECTS.

Co sprawdzić w Nginx i Apache?

Gdy serwis nie korzysta z WordPressa ani Cloudflare, pętla nadal może powstać w konfiguracji Nginx, Apache lub aplikacji. Najczęściej dwie reguły próbują ustawić różne adresy kanoniczne.

W Nginx sprawdź bloki server, dyrektywy return i rewrite, obsługę Host oraz konfigurację reverse proxy. Zwróć uwagę na przypadki, w których przekierowanie z www prowadzi na domenę bez www, a inny blok robi dokładnie odwrotnie. Istotne są też nagłówki przekazywane do aplikacji i to, czy aplikacja poprawnie rozpoznaje zewnętrzny protokół.

Przed zastosowaniem zmian sprawdź składnię konfiguracji:

sudo nginx -t

Dopiero gdy test zakończy się powodzeniem, przeładuj usługę w sposób zgodny z konfiguracją serwera:

sudo systemctl reload nginx

Jeśli używasz Apache, przeanalizuj Redirect, RewriteRule, RewriteCond oraz ewentualne reguły w .htaccess. Reguła opierająca się tylko na informacjach o lokalnym połączeniu HTTP może działać nieprawidłowo za proxy terminującym HTTPS.

Nie ma jednej bezpiecznej reguły, którą można wkleić do każdej konfiguracji. Przed zmianą ustal, która warstwa ma być odpowiedzialna za wybór właściwego adresu. Najprościej utrzymać pojedynczą, przewidywalną politykę i ograniczyć liczbę przekierowań.

Jak naprawić problem bez ryzyka kolejnej awarii?

Jeżeli błąd pojawił się bezpośrednio po aktualizacji, najszybszą metodą przywrócenia dostępności może być wycofanie ostatniej zmiany konfiguracji. Zanim jednak coś wyłączysz, zapisz aktualne ustawienia oraz wyniki testu przekierowań. Ułatwi to późniejsze znalezienie przyczyny.

Praktyczny plan postępowania wygląda następująco:

1. Zapisz adres, na którym występuje błąd, i sprawdź, czy problem dotyczy wszystkich użytkowników.
2. Zbierz łańcuch przekierowań z curl lub zakładki Network.
3. Sprawdź, czy adresy zmieniają protokół (http/https), host (www/bez www) czy ścieżkę.
4. Zidentyfikuj warstwy obsługujące przekierowania: CDN, hosting, serwer WWW, aplikacja i wtyczki.
5. Wybierz docelowy adres kanoniczny i usuń lub popraw regułę, która kieruje ruch w przeciwną stronę.
6. Zweryfikuj certyfikat i sposób przekazywania informacji o HTTPS pomiędzy proxy a aplikacją.
7. Sprawdź ponownie cały łańcuch przekierowań. W typowym przypadku powinien kończyć się poprawną odpowiedzią strony, a nie kolejnym 3xx.
8. Przetestuj stronę główną, podstrony, logowanie, formularze i ścieżki wymagające sesji.
9. Jeśli zmieniłeś domenę lub sposób obsługi HTTPS, sprawdź linki wewnętrzne, adres kanoniczny i mapę witryny.
10. Zapisz przyczynę awarii oraz wprowadź test, który wykryje podobny problem przy następnym wdrożeniu.

Nie rozwiązuj pętli przekierowań przez trwałe wyłączenie HTTPS. Jeżeli źródłem jest konflikt reguł, popraw ich współdziałanie. Prawidłowo zabezpieczona strona powinna pozostać dostępna przez HTTPS z poprawnym certyfikatem.

Czy pętla przekierowań wpływa na SEO?

Tak. Jeśli robot wyszukiwarki trafia na nieskończony albo nieprawidłowy łańcuch przekierowań, nie może dotrzeć do docelowej treści. Utrudnia to indeksowanie i może prowadzić do utraty widoczności problematycznych adresów. To szczególnie istotne po migracji domeny, przebudowie struktury URL lub wdrożeniu nowych reguł HTTPS.

Z punktu widzenia SEO najlepiej, aby ważne stare adresy prowadziły możliwie krótką drogą do właściwej nowej lokalizacji. Przekierowanie 301 lub 308 zwykle jest odpowiednie dla trwałych zmian adresu, a 302 lub 307 dla zmian tymczasowych. O wyborze kodu powinno decydować rzeczywiste przeznaczenie przekierowania, a nie sam zamiar poprawy pozycji w wyszukiwarce.

Po większych zmianach warto przeskanować ważne adresy i sprawdzić, czy każdy prowadzi do oczekiwanej strony. Jeżeli planujesz migrację, przeczytaj też poradnik przebudowa strony internetowej bez utraty ruchu.

Jak wykrywać podobne problemy automatycznie?

Pętla przekierowań może pojawić się nie tylko po ręcznej zmianie konfiguracji, ale także po wdrożeniu nowej wersji aplikacji, zmianie reguł CDN czy aktualizacji wtyczki. Warto więc testować nie tylko to, czy serwer zwraca odpowiedź, ale również czy końcowy adres jest poprawny i czy liczba przekierowań mieści się w rozsądnym limicie.

Dla najważniejszych stron można uruchomić cykliczny test HTTP, który podąża za przekierowaniami i sprawdza końcowy kod odpowiedzi. Osobne testy warto przygotować dla domeny głównej, wariantu www, wersji HTTP oraz adresu logowania. Niektóre problemy z sesją wymagają dodatkowo scenariusza wykonywanego przez przeglądarkę.

Pomocne są też powiadomienia o awariach. Usługi takie jak Ping.pl umożliwiają regularne sprawdzanie dostępności stron, co pozwala zauważyć problem bez czekania na zgłoszenie od użytkownika. Warto jednak upewnić się, jak dany monitor traktuje przekierowania oraz jaki końcowy rezultat uznaje za sukces.

Więcej o wyborze testów i progów alertowania znajdziesz w artykule o monitoringu dostępności strony.

Najczęstsze pytania

Czy wyczyszczenie ciasteczek zawsze naprawia ERR_TOO_MANY_REDIRECTS?

Nie. Usunięcie ciasteczek może pomóc, jeśli problem dotyczy sesji logowania lub nieprawidłowego stanu zapisanego w przeglądarce. Nie naprawi jednak sprzecznych reguł na serwerze, które dotyczą wszystkich użytkowników.

Czy ERR_TOO_MANY_REDIRECTS oznacza problem z DNS?

Zwykle nie. DNS odpowiada za ustalenie adresu IP serwera, natomiast przekierowania HTTP dotyczą kolejnych adresów URL. Problemy mogą występować równocześnie, ale wymagają osobnej diagnostyki. Jeśli podejrzewasz błędne rekordy domeny, przeczytaj jak sprawdzić, czy DNS działa poprawnie.

Czy przeglądarka zawsze pokazuje te same przekierowania co curl?

Nie zawsze. Serwer może zwracać inne odpowiedzi zależnie od ciasteczek, nagłówków, logowania lub urządzenia. Ponadto curl nie wykonuje JavaScriptu strony, więc nie wykryje przekierowań realizowanych wyłącznie przez skrypty w przeglądarce.

Czy wystarczy wyłączyć przekierowanie na HTTPS?

Nie jest to zalecane rozwiązanie. Najpierw ustal, skąd pochodzi pętla. Zwykle należy usunąć konflikt pomiędzy regułami lub poprawić konfigurację proxy, zachowując bezpieczne połączenie HTTPS.

Podsumowanie

Błąd ERR_TOO_MANY_REDIRECTS informuje, że przeglądarka nie może dotrzeć do strony, ponieważ trafia na pętlę lub zbyt długi łańcuch przekierowań. Użytkownik może sprawdzić tryb prywatny i dane witryny, ale powtarzający się problem najczęściej wynika z konfiguracji strony.

Administrator powinien zacząć od odczytania kolejnych adresów i nagłówków Location, a następnie porównać ustawienia HTTPS, domeny, CDN, serwera WWW i aplikacji. Naprawa polega na wyeliminowaniu sprzecznych reguł, przetestowaniu docelowego adresu i wdrożeniu kontroli, która wykryje podobny błąd w przyszłości.