Przeglądarka pokazuje ERR_TOO_MANY_REDIRECTS, gdy kolejne odpowiedzi 301/302 prowadzą ją w kółko. W WordPressie klasyczny przypadek wygląda tak: jedna warstwa wymusza HTTPS, druga „widzi” połączenie jako HTTP i odsyła z powrotem. Podobny konflikt może dotyczyć www/bez www, końcowego slasha, panelu logowania albo reguł wtyczki SEO.
Szybka odpowiedź
Nie zaczynaj od kasowania wszystkich przekierowań. Najpierw zobacz łańcuch odpowiedzi: z jakiego URL-u wychodzisz, dokąd prowadzi pierwszy Location, co zwraca kolejny adres. Kilka poleceń curl -I lub narzędzie do śledzenia redirectów zwykle pokazuje, które dwa adresy ping-pongują między sobą.
HTTP i HTTPS za reverse proxy
Gdy TLS kończy się na load balancerze lub CDN, backend może otrzymywać ruch jako HTTP. Jeśli WordPress nie dostaje poprawnej informacji o pierwotnym protokole, sam wymusza HTTPS, a proxy znów przekazuje żądanie w sposób, który uruchamia tę samą regułę. Rozwiązaniem jest prawidłowa konfiguracja nagłówków i zaufania do proxy, nie wyłączenie HTTPS.
www kontra bez www
Jeśli CDN wymusza www, Nginx bez www, a WordPress ma siteurl w jeszcze innym wariancie, powstaje pętla. Wybierz jeden adres kanoniczny i doprowadź do tego, aby wszystkie warstwy zgodnie kierowały właśnie do niego. To pomaga także SEO, bo nie mnożysz wariantów tego samego URL-u.
home i siteurl w WordPressie
Dwie wartości WordPressa określają adres aplikacji i witryny. Po migracji lub zmianie domeny potrafią pozostać stare dane. Jeśli panel jest niedostępny, można je zweryfikować w bazie albo czasowo zdefiniować w wp-config.php, ale rób to świadomie i pamiętaj o późniejszym uporządkowaniu źródła prawdy.
Wtyczki redirect/SSL/cache
Kilka wtyczek może niezależnie wymuszać ten sam protokół lub adres. Do tego dochodzą reguły serwera i CDN. Dublowanie funkcji zwiększa ryzyko konfliktu. Po ustaleniu docelowej polityki zostaw wymuszanie adresu możliwie nisko w stosie, a w WordPressie unikaj niepotrzebnych dodatkowych przekierowań.
Pętla tylko po logowaniu
Jeżeli publiczna strona działa, ale wp-admin krąży między logowaniem a panelem, sprawdź cookies, domenę sesji i cache dla stron administracyjnych. Panelu oraz ekranów logowania nie powinno się cachować jak zwykłych stron publicznych.
Jak potwierdzić, że naprawa naprawdę działa?
Po naprawie sprawdź łańcuch przekierowań dla czterech wariantów: http://, https://, www i bez www. Każdy niekanoniczny wariant powinien kończyć się po możliwie małej liczbie kroków na jednym docelowym adresie. Osobno przetestuj /wp-login.php, ponieważ sesja i cookies potrafią ujawnić pętlę niewidoczną na publicznej stronie. Narzędzia typu curl -IL pokazują sekwencję bez wpływu cache przeglądarki.
Co obserwować po zmianie?
Po wdrożeniu przejrzyj logi 301/302 i sprawdź, czy nie powstały długie łańcuchy. W SEO oraz wydajności lepiej kierować bezpośrednio do adresu docelowego. Jeżeli korzystasz z CDN, wyczyść tylko potrzebny cache i sprawdź odpowiedź originu osobno, aby stara reguła na edge nie maskowała poprawionej konfiguracji serwera.
Kiedy przekazać temat dalej?
Eskalacja jest potrzebna, gdy domena przechodzi przez kilka warstw proxy, a nie masz pewności, gdzie kończy się TLS i kto ustawia nagłówek X-Forwarded-Proto. Pętle logowania lub pętle tylko dla części użytkowników często wymagają analizy cookies i cache, nie kolejnego redirectu w WordPressie.
Praktyczny scenariusz diagnostyczny
Klasyczny scenariusz to migracja za reverse proxy: użytkownik otwiera HTTPS, proxy przekazuje ruch do backendu, a WordPress „widzi” HTTP i próbuje ponownie przekierować na HTTPS. Proxy znów trafia do backendu i pętla się zamyka. W takiej sytuacji kasowanie cookies może chwilowo zmienić zachowanie przeglądarki, ale nie naprawi architektury. Sprawdź kolejne nagłówki Location, wartości home i siteurl, konfigurację proxy oraz sposób przekazywania informacji o protokole. Po naprawie wykonaj curl -I dla HTTP i HTTPS, wariantu z www i bez www, a także dla logowania. Dobra konfiguracja ma jeden przewidywalny łańcuch przekierowań, nie kilka warstw, które próbują „naprawiać HTTPS” niezależnie od siebie.
Bezpieczna kolejność działań
- Zapisz pełny adres, na którym przeglądarka zgłasza pętlę.
- Prześledź kolejne nagłówki
Location. - Ustal jeden wariant: HTTPS + www albo HTTPS bez www.
- Porównaj ustawienia CDN/proxy, serwera i
home/siteurl. - Wyłącz dublujące się reguły przekierowań tylko po kopii konfiguracji.
- Wyczyść właściwe warstwy cache i przetestuj ponownie.
Czego nie robić
Nie wyłączaj HTTPS tylko po to, aby pętla zniknęła. Nie dodawaj kolejnego redirectu do .htaccess, jeśli nie wiesz, jakie reguły już działają w CDN i serwerze. Każda dodatkowa warstwa może stworzyć kolejny konflikt.
Powiązane poradniki HeatLogic
Potrzebujesz pomocy?
Jeżeli przekierowania przechodzą przez CDN, Nginx i WordPress, możemy rozrysować cały łańcuch i ustawić jeden kanoniczny schemat adresów bez wyłączania SSL ani SEO-friendly redirectów.
Najczęściej zadawane pytania
Czy wyczyszczenie cookies może pomóc?
Tak, gdy pętla dotyczy sesji lub logowania, ale jeśli serwer zwraca cykliczne 301/302, trzeba poprawić konfigurację po stronie serwera.
Czy Cloudflare może powodować pętlę?
Tak, jeśli tryb SSL lub reguły przekierowań są niespójne z konfiguracją serwera origin.
Czy wtyczka SEO może być przyczyną?
Może, jeśli zarządza przekierowaniami i dubluje reguły z serwera lub innego dodatku.
Czy pętla przekierowań szkodzi SEO?
Tak, robot nie dociera do treści, a błędne warianty adresów utrudniają kanonikalizację i indeksację.