Jak naprawić pętlę przekierowań (ERR_TOO_MANY_REDIRECTS) w WordPressie?

Pętla przekierowań to sekwencja, w której adres A kieruje na adres B, a B z powrotem na A, więc przeglądarka po 20 skokach przerywa wczytywanie z kodem ERR_TOO_MANY_REDIRECTS. W WordPressie pojawia się najczęściej po przejściu na https, po podłączeniu Cloudflare albo gdy dwie wtyczki lub reguły przekierowują ten sam adres. Naprawa zaczyna się od sprawdzenia, które adresy się wymieniają i kto wysyła każde przekierowanie. Pętla to inne zjawisko niż łańcuch przekierowań, który kończy się treścią.

Od czego zacząć naprawę pętli przekierowań?

W polskim Chrome pętla wygląda tak: komunikat „Ta strona nie działa”, pod nim zdanie „Strona … spowodowała zbyt wiele przekierowań” i kod ERR_TOO_MANY_REDIRECTS. Zacznij od sprawdzenia, czy winna nie jest przeglądarka: otwórz ten sam adres w oknie prywatnym albo w innym programie. Przeglądarka zapamiętuje przekierowania 301 i ciasteczka strony, więc nawet po naprawie na serwerze może dalej pokazywać stary błąd.

Jeśli w oknie prywatnym strona działa, przyczyna leży w przeglądarce: usuń pliki cookie i dane tej jednej witryny. Jeśli błąd pojawia się i tam, problem tkwi w konfiguracji strony, serwera albo Cloudflare. Zanim cokolwiek zmienisz, zrób kopię plików wp-config.php i .htaccess, bo dalsze kroki edytują właśnie je.

Jak sprawdzić, które adresy wymieniają się w pętli?

Najszybciej sprawdzisz to poleceniem curl w terminalu. Pokazuje ono każdy skok z nagłówkiem Location, czyli adresem, na który serwer odsyła:

curl -sIL --max-redirs 10 https://domena.pl/ | grep -iE "^HTTP|^location|^server|^x-redirect-by|^cf-ray"

Flaga -L każe podążać za przekierowaniami, a --max-redirs 10 przerywa pętlę po dziesięciu skokach komunikatem curl: (47) Maximum (10) redirects followed. Przykładowy wynik pętli na stronie za Cloudflare:

HTTP/2 301
server: cloudflare
cf-ray: 8c1f...-WAW
location: https://domena.pl/

HTTP/2 301
server: cloudflare
cf-ray: 8c1f...-WAW
location: https://domena.pl/

Ten sam blok powtarza się aż do limitu, bo adres przekierowuje sam na siebie. Bez terminala tę samą sekwencję pokażą narzędzia deweloperskie Chrome: naciśnij F12, otwórz zakładkę Network, zaznacz „Preserve log” i wczytaj stronę ponownie. Po kliknięciu wiersza z kodem 301 lub 302 nagłówek Location zobaczysz w sekcji Response Headers.

W wyniku szukasz adresów, które się powtarzają. Albo adres odsyła sam na siebie, albo para adresów różni się jednym elementem: protokołem (http i https), subdomeną (www i bez www), ukośnikiem na końcu albo zamianą zwykłej strony na wp-login.php.

Jak ustalić, kto wysyła przekierowanie?

Nadawcę każdego skoku zdradzają nagłówki odpowiedzi, które curl wypisał razem z adresem:

• X-Redirect-By: WordPress: przekierowanie wysłał WordPress. Od wersji 5.1 nagłówek dodaje funkcja wp_redirect(), a wtyczki mogą wpisać w nim własną nazwę.
• server: cloudflare i cf-ray, bez X-Redirect-By: odpowiedź przyszła przez Cloudflare, więc przekierowanie wysłała reguła Cloudflare albo serwer za nim. Rozróżnisz je, wstrzymując na chwilę Cloudflare dla domeny (opcja „Pause Cloudflare on Site” w panelu) i powtarzając test.
• Brak obu: przekierowanie wysłał serwer, czyli reguła w .htaccess, konfiguracja Nginx albo opcja wymuszania https w panelu hostingu.

Brak nagłówka X-Redirect-By nie wyklucza WordPressa, bo wtyczka może go wyłączyć filtrem x_redirect_by. Nagłówki dają jednak dobry punkt startu: wiesz, w którym miejscu szukać pierwszej reguły pętli, a w którym drugiej.

Jak dopasować objaw do przyczyny pętli przekierowań?

Para adresów i nadawca każdego skoku wskazują przyczynę. Tabela zbiera układy, które w WordPressie powtarzają się najczęściej:

Jeśli w pętli biorą udział trzy adresy, rozpisz każdy skok osobno i dopasuj go do wiersza tabeli. Pętla zawsze ma co najmniej dwie reguły, a naprawa polega na usunięciu albo poprawieniu jednej z nich, nie na dopisaniu trzeciej.

Jak poprawić Adres WordPressa i Adres witryny, gdy pętla blokuje panel?

Oba pola muszą mieć ten sam protokół i ten sam host, do którego kieruje serwer, na przykład https://domena.pl bez ukośnika na końcu. Gdy panel działa, poprawisz je w zakładce Ustawienia → Ogólne: „Adres WordPressa (URL)” to adres plików WordPressa, a „Adres witryny (URL)” to adres, pod którym odwiedzający widzą stronę. Po zapisie WordPress wyloguje Cię i poprosi o ponowne logowanie pod nowym adresem.

Gdy pętla blokuje wp-admin, dopisz w wp-config.php, przed linią „That’s all, stop editing!”, dwie stałe:

define( 'WP_HOME', 'https://domena.pl' );
define( 'WP_SITEURL', 'https://domena.pl' );

Stałe mają pierwszeństwo przed wartościami zapisanymi w bazie danych, ale ich nie zmieniają. Pola w ustawieniach stają się wtedy nieaktywne, więc jeśli widzisz je wyszarzone, adres ustawia już wp-config.php i błędnej wartości trzeba szukać właśnie tam. Drugi sposób bez panelu to phpMyAdmin: w tabeli wp_options (prefiks może być inny) wiersz siteurl odpowiada Adresowi WordPressa, a home Adresowi witryny.

Jak naprawić pętlę przekierowań po włączeniu Cloudflare?

Sprawdź tryb szyfrowania w sekcji SSL/TLS panelu Cloudflare. W trybie Flexible połączenie Cloudflare z serwerem idzie przez nieszyfrowane http, więc serwer, który przekierowuje każde żądanie http na https, odsyła je w kółko. Dokumentacja Cloudflare podaje dwa wyjścia: usunąć przekierowanie http → https na serwerze albo przejść na tryb Full lub Full (strict), który wymaga certyfikatu SSL na serwerze.

Lepszy jest tryb Full (strict), bo szyfruje także połączenie między Cloudflare a serwerem i sprawdza certyfikat. Przekierowanie http → https zostaje wtedy na serwerze jako jedna reguła, opisana we wpisie jak przenieść stronę z http na https.

Trzy pozostałe układy według dokumentacji Cloudflare:

• Full lub Full (strict) i przekierowanie https → http na serwerze: usuń to przekierowanie z serwera albo z WordPressa (Adres witryny z http://).
• „Always Use HTTPS” i przekierowanie https → http na serwerze: Cloudflare kieruje na https, a serwer z powrotem na http, więc usuń regułę serwera albo wyłącz tę opcję.
• Reguły przekierowań w Cloudflare (Redirect Rules, Page Rules) sprzeczne ze sobą albo z regułą serwera: zostaw przekierowanie w jednym miejscu.

Po każdej zmianie wyczyść cache Cloudflare i wtyczki cache w WordPressie, a test powtórz w oknie prywatnym.

Jak naprawić pętlę https za serwerem proxy?

Gdy certyfikat obsługuje serwer proxy (Cloudflare, load balancer hostingu, Nginx przed Apache), a sam WordPress dostaje ruch przez http, uznaje on każde żądanie za nieszyfrowane i przekierowuje je na https. Dokumentacja WordPressa (Advanced Administration Handbook, strona „HTTPS”) opisuje to wprost jako nieskończoną pętlę przekierowań i podaje rozwiązanie: odczytać nagłówek X-Forwarded-Proto, który proxy dopisuje do żądania.

Kod dopisz w wp-config.php, przed linią „That’s all, stop editing!”:

if ( isset( $_SERVER['HTTP_X_FORWARDED_PROTO'] ) && strpos( $_SERVER['HTTP_X_FORWARDED_PROTO'], 'https' ) !== false ) {
    $_SERVER['HTTPS'] = 'on';
}

Warunek ustawia $_SERVER['HTTPS'] na on, gdy proxy zgłasza, że odwiedzający połączył się przez https, więc WordPress przestaje przekierowywać. Kod ma sens tylko wtedy, gdy proxy rzeczywiście dopisuje ten nagłówek; hosting potwierdzi to w jednej wiadomości. Przy Cloudflare w trybie Flexible kod usuwa pętlę, ale ruch do serwera dalej idzie bez szyfrowania, dlatego docelowym rozwiązaniem jest tryb Full (strict).

Jak znaleźć konflikt dwóch wtyczek lub reguł przekierowań?

Ustal, która warstwa ma wymuszać https i wersję adresu (z www albo bez), a w pozostałych tę funkcję wyłącz. Typowy konflikt to wtyczka wymuszająca https, reguła w .htaccess i opcja „wymuś https” w panelu hostingu włączone jednocześnie, każda z innym celem. Najszybsza i najprostsza w utrzymaniu jest jedna reguła na serwerze.

Przekierowania pojedynczych adresów trzymaj w jednej wtyczce. Reguła A → B w Rank Math i B → A we wtyczce Redirection tworzą pętlę, której żadna z wtyczek nie widzi w całości; więcej o wyborze jednego źródła reguł we wpisie jak ustawić przekierowanie 301 w WordPressie. Osobny przypadek to wzorzec regex bez znaku ^, który łapie także własny adres docelowy, opisany we wpisie o przekierowaniach adresów z parametrami i wzorcami regex.

Gdy nagłówki nie wskazują winnej wtyczki, a panel jest niedostępny, wyłącz wtyczki, zmieniając przez FTP nazwę folderu wp-content/plugins/, a potem w ten sam sposób sprawdź plik .htaccess. Oba kroki opisuje instrukcja jak naprawić błąd 500 w WordPressie, a przy pętli działają tak samo.

Jak sprawdzić, że pętla przekierowań zniknęła?

Powtórz test curl z początku: poprawny wynik to najwyżej jedno przekierowanie 301 i odpowiedź 200. Sprawdź kilka rodzajów adresów: stronę główną, wpis, /wp-admin/ oraz wersje z http:// i z www, bo pętla bywa ograniczona do jednej z nich.

Przed testem w przeglądarce wyczyść cache wtyczki (LiteSpeed Cache, WP Rocket) i Cloudflare, a stronę otwórz w oknie prywatnym. Jeśli Search Console zgłosiła wcześniej adresy z błędem przekierowania, sprawdź je narzędziem „Sprawdzanie adresu URL” i uruchom walidację poprawki w raporcie Strony.

FAQ

Źródła

• Cloudflare Docs, „ERR_TOO_MANY_REDIRECTS”: developers.cloudflare.com
• WordPress.org, Advanced Administration Handbook, „HTTPS” (reverse proxy, HTTP_X_FORWARDED_PROTO): developer.wordpress.org
• WordPress.org, Advanced Administration Handbook, „Editing wp-config.php” (WP_HOME, WP_SITEURL): developer.wordpress.org
• WordPress Developer Resources, filtr x_redirect_by: developer.wordpress.org
• WHATWG, „Fetch Standard”, HTTP-redirect fetch (limit 20 przekierowań): fetch.spec.whatwg.org
• Google Search Central, „Kody stanu HTTP oraz błędy sieci i DNS”: developers.google.com