Pętla przekierowań WordPress: jak znaleźć źródło ERR_TOO_MANY_REDIRECTS

Pętla przekierowań występuje, gdy kolejne odpowiedzi HTTP kierują przeglądarkę między adresami bez dostarczenia strony. ERR_TOO_MANY_REDIRECTS to komunikat przeglądarki informujący, że liczba przekierowań przekroczyła limit obsługiwany przez klienta. Łańcuch przekierowań to kolejne przejścia między adresami; pojedyncze przekierowanie nie jest błędem, jeśli prowadzi do odpowiedzi końcowej.

Zapisz dokładny adres początkowy, adresy pośrednie, kody odpowiedzi i nagłówki lokalizacji. W narzędziach deweloperskich przeglądarki otwórz kartę Network, włącz zachowanie logu nawigacji i odśwież problematyczny adres. Zapisz, czy przejście zmienia protokół http/https, wariant www, ścieżkę czy końcówkę ukośnika.

Tabela pomaga powiązać widoczny objaw z warstwą do sprawdzenia i potrzebnym pomiarem. Kody statusu należy odczytywać w kolejności, w jakiej otrzymuje je przeglądarka.

Tabela pokazuje, że zmiana hosta, protokołu lub ścieżki naprowadza na warstwę wymagającą pomiaru. Jeśli błąd pojawia się wyłącznie w jednej przeglądarce, sprawdź go również w prywatnym oknie, ale zachowaj pierwotny ślad przed czyszczeniem danych.

Różne wartości adresu WordPressa i adresu witryny mogą powodować przekierowania do innej domeny lub protokołu. W panelu WordPress przejdź do Ustawienia > Ogólne i sprawdź pola "Adres WordPressa (URL)" oraz "Adres witryny (URL)". WordPress dokumentuje także ręczne ustawienie tych wartości przez stałe WP_HOME i WP_SITEURL w pliku wp-config.php; sprawdziliśmy dokumentację w październiku 2026.

Przed zmianą ustal docelową wersję adresu, na przykład https://example.pl albo https://www.example.pl, i porównaj ją z adresem końcowym w śladzie przekierowań. Sprawdź, czy certyfikat TLS obejmuje wybrany host i czy domena wskazuje na właściwy serwer. Jeśli panel nie działa, nie zmieniaj bazy danych w ciemno: wykonaj kopię plików i bazy, a potem użyj zatwierdzonej metody administratora.

Stałe WP_HOME i WP_SITEURL w wp-config.php mogą nadpisywać wartości zapisane w panelu. Zmiana w panelu nie przyniesie skutku, gdy aktywne stałe nadal wskazują inny adres. Po korekcie sprawdź dostęp do /wp-admin/ i /wp-login.php przed usuwaniem cache.

Jeśli pętla blokuje dostęp do panelu albo nie masz pewności, którą wartość zmienić, naprawa WordPressa z diagnostyką przekierowań może objąć sprawdzenie adresów i warstw HTTPS.

Wtyczki, plik .htaccess i konfiguracja serwera mogą niezależnie wymuszać ten sam wariant URL, dlatego sprawdzamy je osobno. Zrób kopię przed edycją pliku i najpierw przetestuj zmianę na kopii witryny. WordPress opisuje, że na Apache plik .htaccess obsługuje między innymi reguły ładnych odnośników, a przy Nginx reguły są konfigurowane na poziomie serwera; stan dokumentacji sprawdziliśmy w październiku 2026.

Zalecana kolejność izolacji:

1. Zapisz aktywne wtyczki i sprawdź, czy problem wystąpił po aktualizacji lub zmianie konfiguracji. Na kopii wyłącz jedną wtyczkę odpowiedzialną za HTTPS, cache albo przekierowania i powtórz ten sam test.
2. Na Apache sprawdź kopię .htaccess, szczególnie reguły przed i po blokach WordPressa. Nie kasuj całego pliku: mogą znajdować się w nim reguły przekierowań i ochrony dodane przez administratora.
3. Przy Nginx poproś administratora o sprawdzenie bloku server i reguł return lub rewrite. WordPress nie zarządza plikiem .htaccess w Nginx, bo ten serwer nie używa takiego pliku.
4. Sprawdź ustawienia przekierowań w panelu hostingu, w tym przekierowanie domeny i wymuszanie HTTPS.

Po każdej pojedynczej zmianie wykonaj test tego samego adresu i zapisz rezultat. Jeśli wyłączenie wtyczki usuwa problem, sprawdź jej konfigurację i zależności przed ponownym włączeniem pozostałych reguł.

Tak, CDN może tworzyć pętlę HTTPS, jeśli przeglądarka łączy się z CDN po HTTPS, a CDN łączy się z serwerem po HTTP, który ponownie wymusza HTTPS. Cloudflare opisuje ten przypadek dla trybu Flexible i zaleca tryb Full lub Full (strict), gdy serwer źródłowy sam przekierowuje HTTP do HTTPS; dokumentację sprawdziliśmy w październiku 2026.

Tabela pokazuje, jak sprawdzić zgodność protokołu na kolejnych odcinkach połączenia. Ustawienia CDN zmieniaj dopiero po potwierdzeniu, że serwer źródłowy obsługuje HTTPS i ma właściwy certyfikat.

Tabela pokazuje, że tryb Flexible może wejść w konflikt z wymuszaniem HTTPS na serwerze źródłowym. Wynik diagnostyczny powinien wskazać konkretną warstwę, która odsyła żądanie do wcześniejszego adresu. Przy proxy administrator powinien potwierdzić, jaki protokół serwer widzi w nagłówkach, zamiast dodawać kolejne reguły na próbę.

Źródło pętli można izolować, testując jedną warstwę na raz na kopii witryny lub w kontrolowanym oknie serwisowym. Jednoczesne wyłączenie wtyczek, CDN i reguł serwera utrudnia ustalenie przyczyny oraz może usunąć przekierowania potrzebne do zachowania adresów SEO. Zapisz stan wyjściowy i przygotuj sposób przywrócenia każdej zmiany.

Procedura izolacji:

1. Zrób kopię plików i bazy danych albo potwierdź, że hosting ma aktualny punkt przywracania.
2. Odtwórz błąd na kopii i zapisz odpowiedzi HTTP dla strony głównej, problematycznej podstrony oraz logowania.
3. Zmień tylko jedną rzecz: pojedyncze ustawienie wtyczki, jedną regułę lub tryb proxy. Nie usuwaj wszystkich przekierowań.
4. Powtórz test w tym samym środowisku, z tym samym adresem początkowym i bez zmiany kilku warunków.
5. Jeśli objaw ustąpi, sprawdź sąsiednie adresy i logowanie. Jeśli nie ustąpi, przywróć zmianę i przejdź do kolejnej warstwy.

Witryna produkcyjna wymaga dodatkowej ostrożności, gdy zmiana może odciąć panel lub logowanie. Uzgodnij z hostingiem możliwość szybkiego cofnięcia reguł, zanim edytujesz konfigurację serwera.

Naprawę dobieramy do pierwszego konfliktu znalezionego w łańcuchu, a nie do samego komunikatu ERR_TOO_MANY_REDIRECTS. Jeśli różni się host, ustaw jeden wariant domeny w WordPressie i regułach serwera; jeśli różni się protokół, uzgodnij wymuszanie HTTPS między CDN, proxy i serwerem. Jeśli powtarza się ta sama ścieżka, sprawdź regułę wtyczki lub hostingu, która ją obsługuje.

Po korekcie wykonaj następujące czynności:

• wyczyść cache WordPressa, CDN i przeglądarki dopiero po zapisaniu śladu błędu;
• usuń ciasteczka dla domeny lub sprawdź stronę w nowym profilu, jeśli problem dotyczy sesji;
• otwórz stronę główną i adres, który wcześniej się zapętlał;
• sprawdź, czy przekierowanie kończy się na oczekiwanym adresie, bez powrotu do poprzedniego wariantu.

Jeżeli problem wynika z konfliktu HTTPS między CDN a serwerem, korekta powinna objąć właściwy tryb szyfrowania i tylko jedną spójną regułę wymuszenia protokołu. Konfiguracja Cloudflare zależy od tego, czy serwer źródłowy ma poprawny certyfikat TLS; tryb Full (strict) wymaga certyfikatu, który Cloudflare może zweryfikować.

Naprawa jest zakończona dopiero wtedy, gdy ważne adresy otwierają się poprawnie, logowanie działa, a przekierowania prowadzą do jednego adresu końcowego. Sprawdź stronę główną, kilka typów podstron, /wp-admin/, /wp-login.php, formularz kontaktowy i adresy kanoniczne. Odpowiedź 200 oznacza udane pobranie strony, a 301 to stałe przekierowanie, które powinno prowadzić do właściwego adresu.

Lista odbiorcza po zmianie:

• strona główna zwraca oczekiwaną treść i nie zmienia wariantu hosta ponownie;
• stare adresy przekierowują do docelowych stron, bez cyklu i zbędnych łańcuchów;
• panel, logowanie i sesja użytkownika działają po ponownym zalogowaniu;
• formularze wysyłają dane, a po wysłaniu wyświetla się potwierdzenie;
• adres kanoniczny strony odpowiada wariantowi używanemu w przekierowaniach.

Perspektywa KC Mobile: po naprawie samej strony głównej warto sprawdzić również logowanie i formularze. Te ścieżki używają ciasteczek i sesji, więc mogą ujawnić konflikt, którego nie widać podczas anonimowego wejścia na stronę.

Przekaż problem administratorowi, gdy ślad wskazuje na konfigurację poza WordPressem, do której nie masz dostępu, albo gdy warstwa proxy zwraca sprzeczne informacje o protokole. Eskalacja jest potrzebna również wtedy, gdy nie możesz odtworzyć reguł serwera, hosting zarządza certyfikatem lub błąd powraca po zmianie ustawień w panelu. WordPress wskazuje, że przy Nginx reguły konfiguruje administrator serwera; stan dokumentacji sprawdziliśmy w październiku 2026.

Przekaż administratorowi pakiet diagnostyczny:

• adres początkowy i czas testu;
• zapisane adresy pośrednie wraz z kodami HTTP;
• informację, czy problem występuje z CDN, bez CDN, w panelu i po wylogowaniu;
• ostatnią zmianę konfiguracji, aktualizacji lub certyfikatu przed awarią;
• wynik testu na kopii oraz zmianę, która odtworzyła lub usunęła problem.

Jeżeli błąd blokuje dostęp do strony i nie masz dostępu do reguł serwera, naprawa WordPressa może objąć diagnostykę warstw i przywrócenie poprawnych przekierowań. Przygotowany ślad HTTP skraca ustalanie, czy problem leży w witrynie, hostingu czy proxy.

Usunięcie pliku .htaccess może usunąć część reguł na serwerze Apache, ale może też zepsuć ładne odnośniki i inne ustawienia witryny. WordPress korzysta z tego pliku do obsługi reguł odnośników, a plik może zawierać również konfigurację dodaną przez hosting lub inne wtyczki; dokumentację sprawdziliśmy w październiku 2026. Najpierw pobierz kopię i sprawdź, czy powtarzający się adres rzeczywiście wynika z konkretnej reguły.

Na Nginx plik .htaccess nie steruje konfiguracją serwera. W takim przypadku usunięcie pliku nie naprawi reguły rewrite lub return działającej w konfiguracji Nginx. Administrator powinien zmienić właściwy blok serwera, zachowując reguły potrzebne do obsługi witryny.

• Błąd 414 WordPress: jak znaleźć przyczynę i naprawić zbyt długi adres
• Błąd 404: co oznacza i jak go naprawić na stronie?
• Błąd 503 w WordPressie: jak znaleźć przyczynę i przywrócić stronę
• Błąd strony po przeniesieniu WordPressa: jak znaleźć przyczynę i naprawić problem