ERR_TOO_MANY_REDIRECTS w WordPressie — jak naprawić pętlę | TopHostings.pl

ERR_TOO_MANY_REDIRECTS pojawia się wtedy, gdy przeglądarka wpada w pętlę przekierowań. Serwer kieruje użytkownika pod inny adres, kolejna warstwa odsyła go z powrotem, a sekwencja powtarza się do momentu przerwania jej przez przeglądarkę.

W WordPressie problem często pojawia się po migracji, włączeniu HTTPS, zmianie domeny albo konfiguracji Cloudflare. Nie oznacza to jednak, że przyczyna zawsze znajduje się w samym WordPressie.

Przy pętli przekierowań najważniejsze jest odtworzenie łańcucha: adres A przekierowuje do B, ale coś musi później skierować B z powrotem do A albo ponownie uruchomić tę samą regułę.

Najpierw odtwórz łańcuch przekierowań

Typowy przypadek można sprowadzić do dwóch sprzecznych decyzji:

http://example.pl
→ https://example.pl
→ http://example.pl
→ https://example.pl
→ ...

Pętla nie musi jednak dotyczyć tylko HTTP i HTTPS. Może powstać również między:

www i domeną bez www,
starą i nową domeną,
dwoma wariantami ścieżki URL,
WordPressem i regułą serwera,
originem i reverse proxy lub CDN.

Interesują Cię kolejne odpowiedzi 301, 302, 303, 307 i 308 oraz wartości nagłówka Location. Łańcuch można podejrzeć w narzędziach deweloperskich przeglądarki w zakładce Network albo narzędziem HTTP pokazującym kolejne odpowiedzi i nagłówki Location. Ważne jest zapisanie pełnej kolejności, a nie tylko ostatniego komunikatu przeglądarki.

Łańcuch	Najbardziej prawdopodobny kierunek diagnozy
HTTP → HTTPS → HTTP	Konflikt HTTPS między originem, proxy lub aplikacją
www → bez www → www	Dwie sprzeczne reguły canonical host
stara domena → nowa → stara	Migracja lub nieaktualna reguła redirect
ten sam URL przekierowuje sam do siebie	Błędny warunek reguły lub nieprawidłowe wykrywanie protokołu/hosta

Samo wyczyszczenie cookies może czasem usunąć problem związany z konkretną sesją, ale nie naprawi rzeczywistej pętli HTTP występującej dla każdego użytkownika.

Sprawdź WP_HOME i WP_SITEURL

WordPress przechowuje dwa istotne adresy: WordPress Address (URL) oraz Site Address (URL). Można je również wymusić przez stałe WP_HOME i WP_SITEURL w wp-config.php.

WP_HOME określa publiczny adres witryny, natomiast WP_SITEURL wskazuje adres instalacji WordPressa i jego plików. W zwykłej instalacji często są takie same, ale np. przy WordPressie zainstalowanym w osobnym katalogu mogą się celowo różnić.

Po migracji albo przejściu na HTTPS warto sprawdzić, czy oba adresy używają właściwego protokołu i domeny, wariant www jest zgodny z docelową konfiguracją oraz czy w wp-config.php nie pozostały stare stałe nadpisujące wartości z bazy.

Problem może wyglądać tak: WordPress uważa, że właściwy adres to http://, podczas gdy serwer wymusza https://. Jedna warstwa zmienia protokół w jedną stronę, a aplikacja próbuje wrócić do swojej konfiguracji.

HTTPS, reverse proxy i CDN muszą widzieć ten sam protokół

HTTPS może być wymuszany w kilku miejscach jednocześnie: w panelu hostingu, konfiguracji Apache lub NGINX, .htaccess, WordPressie, wtyczce oraz na warstwie CDN.

Samo posiadanie kilku reguł prowadzących do tego samego celu nie zawsze tworzy pętlę. Problem pojawia się wtedy, gdy poszczególne warstwy mają sprzeczny obraz bieżącego połączenia albo docelowego adresu.

Reverse proxy może przyjąć HTTPS od użytkownika, a następnie połączyć się z originem po HTTP. Jeżeli aplikacja widzi tylko wewnętrzne połączenie HTTP i bez prawidłowej informacji o protokole uznaje, że użytkownika trzeba ponownie przekierować na HTTPS, konfiguracja proxy musi umożliwiać aplikacji prawidłowe rozpoznanie pierwotnego żądania.

Klasyczna pętla Cloudflare Flexible

W trybie Cloudflare Flexible użytkownik łączy się z Cloudflare przez HTTPS, ale Cloudflare komunikuje się z originem przez HTTP. Jeśli origin automatycznie przekierowuje każde żądanie HTTP na HTTPS, powstaje konflikt:

użytkownik → HTTPS → Cloudflare
Cloudflare → HTTP → origin
origin → redirect do HTTPS
Cloudflare → ponownie HTTP → origin
...

W takim układzie rozwiązaniem jest uporządkowanie konfiguracji TLS, a nie dokładanie kolejnego redirectu. W trybie Full lub Full (strict) Cloudflare łączy się z originem przez HTTPS, ale pętla nadal jest możliwa, jeśli origin próbuje przekierowywać HTTPS z powrotem do HTTP albo działają sprzeczne Redirect Rules.

Po migracji sprawdź wszystkie miejsca, które mogą przekierowywać

Po zmianie domeny lub wdrożeniu HTTPS często zostają stare reguły. W .htaccess może istnieć przekierowanie dodane ręcznie, hosting może mieć własne „Force HTTPS”, NGINX własną regułę, a WordPress dodatkowo korzystać z pluginu do redirectów.

Najbezpieczniejsza diagnostyka polega na znalezieniu wszystkich warstw odpowiedzialnych za dany przypadek i pozostawieniu jednej spójnej logiki.

Przy problemie, który pojawił się bezpośrednio po edycji .htaccess, zacznij od diffu ostatniej zmiany zamiast kasowania całego pliku. Jeżeli pętla występuje tylko dla jednej podstrony, większe znaczenie mogą mieć reguły dotyczące konkretnego URL-a lub plugin przekierowań. Jeżeli dotyczy całej domeny, najpierw sprawdź protokół i host.

Migracja często łączy kilka zmian naraz: nowy hosting, nową domenę, HTTPS oraz konfigurację canonical host. Wtedy łatwo utworzyć łańcuch z kilku poprawnych pojedynczo reguł, które razem zaczynają się zapętlać.

stara-domena.pl
→ www.nowa-domena.pl
→ nowa-domena.pl
→ stara-domena.pl

Ostatni redirect może pochodzić z pozostawionej reguły migracyjnej, konfiguracji WordPressa albo warstwy proxy.

Nie jest to problem DNS w ścisłym znaczeniu. DNS wskazuje, dokąd ma trafić połączenie, natomiast pętla 301/302/303/307/308 powstaje już na poziomie HTTP. Po migracji nadal warto jednak upewnić się, że testujesz właściwy serwer. Pomóc może diagnostyka domeny przed migracją.

Jak znaleźć regułę tworzącą pętlę?

Sam łańcuch wskazuje, co się dzieje. Żeby dowiedzieć się dlaczego, zestaw go z konfiguracją i logami.

Docelowy adres. HTTPS czy HTTP, www czy bez www?
WordPress. home, siteurl, WP_HOME, WP_SITEURL.
Serwer. Apache/NGINX i .htaccess.
Hosting. Opcje wymuszania HTTPS lub canonical host.
Proxy/CDN. Tryb TLS i Redirect Rules.
WordPress plugins. Redirecty, SSL, security i cache.

Po każdej zmianie sprawdź ponownie ten sam URL. Zmiana kilku warstw jednocześnie może usunąć objaw, ale nie pokaże, która reguła tworzyła konflikt.

Przy analizie odpowiedzi i logów pomocny może być również poradnik o error_log i debug.log, choć sama pętla może zachodzić jeszcze przed pełnym uruchomieniem WordPressa.

Najważniejsze wnioski

ERR_TOO_MANY_REDIRECTS oznacza pętlę przekierowań, a nie konkretną awarię WordPressa;
najpierw trzeba odtworzyć rzeczywisty łańcuch HTTP i wskazać adresy, między którymi krąży żądanie;
w łańcuchu mogą występować odpowiedzi 301, 302, 303, 307 i 308;
WP_HOME i WP_SITEURL mają różne znaczenie i nie zawsze muszą być identyczne;
HTTPS może być wymuszany w kilku warstwach, ale wszystkie muszą mieć zgodny obraz docelowego adresu;
Cloudflare Flexible połączony z originem wymuszającym HTTPS może utworzyć klasyczną pętlę;
pętla może wynikać z konfliktu między .htaccess, NGINX, panelem hostingu, pluginem i CDN;
DNS nie generuje odpowiedzi redirect, ale po migracji trzeba upewnić się, że testowany ruch trafia do właściwego originu;
naprawa powinna usuwać sprzeczną regułę, a nie dodawać następne przekierowanie.

Źródła

RFC 9110 — HTTP Semantics — semantyka przekierowań 301, 302, 303 i 307 oraz nagłówka Location.
RFC 7538 — The Hypertext Transfer Protocol Status Code 308 — kod 308 Permanent Redirect.
WordPress Developer Resources — Editing wp-config.php — WP_HOME, WP_SITEURL i konfiguracja adresów WordPressa.
WordPress Developer Resources — wp_redirect() — mechanizm przekierowań WordPressa.
Apache HTTP Server — URL Rewriting Guide — reguły mod_rewrite i przekierowania na poziomie serwera.
Cloudflare — ERR_TOO_MANY_REDIRECTS — pętle związane z TLS i regułami redirect.
Cloudflare — Flexible SSL/TLS — sposób połączenia Cloudflare z originem i ryzyko pętli przy wymuszaniu HTTPS.
Cloudflare — Full (strict) — szyfrowane połączenie do originu i wymagania certyfikatu.
Cloudflare — Always Use HTTPS — przekierowanie HTTP do HTTPS na edge i ryzyko konfliktu z redirectami originu.