ERR_TOO_MANY_REDIRECTS: jak to naprawic (wszystkie przegladarki)

Czym jest ERR_TOO_MANY_REDIRECTS?

ERR_TOO_MANY_REDIRECTS to blad przegladarki, ktory wystepuje, gdy witryna wpada w nieskonczona petle przekierowan. Zamiast zaladowac strone, przegladarka ciagle przeskakuje miedzy adresami URL, a po osiagnieciu limitu przekierowan poddaje sie i wyswietla ten blad.

Kazda przegladarka ma wbudowany limit przekierowan, ktory zapobiega nieskonczonej petli pochlaniajacej zasoby. Gdy strona przekroczy ten limit, polaczenie zostaje przerwane z komunikatem o bledzie.

Kody statusu HTTP w petli przekierowan to zazwyczaj 301 (przekierowanie stale) lub 302 (przekierowanie tymczasowe). Typowa petla wyglada nastepujaco: przegladarka wysyla zadanie do URL A, serwer odpowiada kodem 301 na URL B, URL B odpowiada kodem 301 z powrotem na URL A, a cykl powtarza sie, az przegladarka osiagnie limit.

Co powoduje petle przekierowan?

Petle przekierowan wystepuja, gdy dwie lub wiecej regul przekierowan wchodzi ze soba w konflikt. Serwer wysyla przegladarke na URL, a ten URL wysyla przegladarke z powrotem. Oto najczestsze przyczyny:

• Bledna konfiguracja SSL/HTTPS — Najczestsza przyczyna. Twoj serwer wymusza HTTP na HTTPS, ale CDN lub load balancer laczy sie z serwerem po HTTP, tworzac petle: CDN -> HTTP -> serwer przekierowuje na HTTPS -> CDN usuwa HTTPS -> HTTP -> petla

• Cloudflare Flexible SSL — Tryb Flexible SSL w Cloudflare wysyla zadania do serwera po HTTP. Jesli serwer rowniez wymusza przekierowanie HTTP na HTTPS, powstaje nieskonczona petla miedzy Cloudflare a serwerem

• Kolidujace reguly w .htaccess — Wiele regul przekierowan w .htaccess, ktore sobie przecza, np. jedna regula wymuszajaca www, a druga wymuszajaca bez www jednoczesnie

• Niezgodnosc URL w WordPress — Adres WordPress (URL) i Adres witryny (URL) w Ustawienia > Ogolne nie sa zgodne, lub jeden uzywa HTTP, a drugi HTTPS

• Przestarzale pliki cookie przegladarki — Stare pliki cookie zawierajace nieaktualne instrukcje przekierowan lub dane sesji, ktore kieruja przegladarke na URL, ktory juz nie istnieje lub zostal przeniesiony

• Przekierowania w cache CDN lub proxy — CDN zapamietal stare przekierowanie 301, ktore teraz koliduje z aktualna konfiguracja serwera

• Konflikty konfiguracji serwera — Pliki konfiguracyjne Nginx lub Apache z konkurujacymi blokami przekierowan, np. przekierowanie zarowno w bloku serwera, jak i w .htaccess jednoczesnie

Jak zdiagnozowac petle przekierowan

Zanim zaczniesz probowac poprawek, zidentyfikuj dokladny lancuch przekierowan. To pokaze, ktore dokladnie adresy URL sa zaangazowane i ktore reguly przekierowan powoduja petle.

Metoda 1: Uzyj curl do sledzenia przekierowan

Najszybszym sposobem na zobaczenie lancucha przekierowan jest uzycie curl w terminalu. Flaga -I pobiera tylko naglowki, -L podaza za przekierowaniami, a --max-redirs ogranicza ich liczbe:

# Trace redirect chain (limit to 10 hops)
curl -ILs --max-redirs 10 https://example.com 2>&1 | grep -i 'HTTP/\|location:'

# Example output showing a redirect loop:
# HTTP/2 301
# location: http://example.com/
# HTTP/1.1 301 Moved Permanently
# Location: https://example.com/
# HTTP/2 301
# location: http://example.com/
# (repeats...)

Jesli widzisz te same dwa adresy URL naprzemiennie w naglowkach Location, potwierdziles petle przekierowan. Zwroc uwage na kody statusu HTTP: 301 oznacza przekierowanie stale (buforowane przez przegladarki), 302 oznacza tymczasowe (nie buforowane).

Metoda 2: Karta Network w DevTools przegladarki

Mozesz rowniez sledzic przekierowania wizualnie w Chrome DevTools:

• Krok 1 — Otworz Chrome DevTools za pomoca F12 lub Ctrl+Shift+I (Mac: Cmd+Option+I)

• Krok 2 — Przejdz do karty Network i zaznacz Preserve log (zachowuje wpisy miedzy przekierowaniami)

• Krok 3 — Zaladuj strone, ktora wywoluje blad

• Krok 4 — Sprawdz sekwencje zadan. Kazde przekierowanie pojawia sie jako osobny wpis ze statusem 301 lub 302. Kolumna Location pokazuje, dokad wskazuje kazde przekierowanie

Karta Network pokazuje pelny lancuch przekierowan w kolejnosci chronologicznej. Zobaczysz wzorzec — zazwyczaj dwa lub trzy adresy URL powtarzajace sie cyklicznie. Uzyj HTTP Headers Checker od DNS Robot, aby sprawdzic naglowki odpowiedzi poza pamiecia podreczna przegladarki.

Metoda 3: Sprawdzanie przekierowan online

Jesli nie masz dostepu do terminala, uzyj Redirect Checker od DNS Robot, aby prosledzic pelny lancuch przekierowan. Wpisz URL, a narzedzie pokaze kazdy skok, kod statusu i ostateczny cel — lub potwierdzi istnienie petli. Jest to przydatne, poniewaz sprawdza z neutralnej lokalizacji bez wplywu plikow cookie przegladarki na wynik.

Poprawka 1: Wyczysc pliki cookie i pamiec podreczna przegladarki

Zacznij od najprostszej poprawki. Przestarzale pliki cookie lub buforowane przekierowania w przegladarce moga powodowac petle nawet przy prawidlowej konfiguracji serwera. Jest to szczegolnie czeste po migracji witryny z HTTP na HTTPS — stare pliki cookie moga nadal odwolywac sie do adresow HTTP.

Czyszczenie plikow cookie w Chrome

Wyczysc pliki cookie dla konkretnej witryny, a nie wszystkie — to zachowa Twoje logowania na innych stronach:

• Krok 1 — Kliknij ikone klodki (lub ikone ustawien) na pasku adresu obok URL

• Krok 2 — Kliknij Ustawienia witryny

• Krok 3 — Kliknij Wyczysc dane, aby usunac pliki cookie i dane w cache tylko dla tej witryny

• Krok 4 — Przeladuj strone

# Chrome keyboard shortcut to open Clear Browsing Data:
# Windows/Linux: Ctrl + Shift + Delete
# macOS: Cmd + Shift + Delete

Alternatywnie przejdz do chrome://settings/clearBrowserData, zaznacz Pliki cookie i inne dane witryn oraz Obrazy i pliki w pamieci podrecznej, ustaw zakres czasowy na Caly czas i kliknij Wyczysc dane.

Czyszczenie plikow cookie w Firefox i Safari

Firefox: Nacisnij Ctrl+Shift+Delete (Mac: Cmd+Shift+Delete), zaznacz Ciasteczka i Pamiec podreczna, ustaw zakres czasowy na Wszystko i kliknij Wyczysc teraz.

Safari: Przejdz do Safari > Ustawienia > Prywatnosc > Zarzadzaj danymi witryn, wyszukaj dany domen, zaznacz go i kliknij Usun. Nastepnie wyczysc pamiec podreczna skrotem Cmd+Option+E.

Poprawka 2: Sprawdz konfiguracje SSL/HTTPS

Bledna konfiguracja SSL to przyczyna nr 1 petli przekierowan. Najczestszy scenariusz to konflikt miedzy CDN/proxy a serwerem zrodlowym co do uzycia HTTP lub HTTPS.

Oto co zazwyczaj idzie nie tak: CDN laczy sie z serwerem po HTTP (poniewaz obsluguje terminacje SSL), ale serwer wymusza przekierowanie HTTP na HTTPS. Serwer odsyla CDN na HTTPS, CDN usuwa HTTPS i ponownie wysyla HTTP — nieskonczona petla.

• Sprawdz certyfikat SSL — Uzyj SSL Checker od DNS Robot, aby zweryfikowac, ze certyfikat jest wazny, nie wygasl i obejmuje poprawna domene

• Dopasuj protokoly — Jesli CDN obsluguje terminacje SSL, usun przekierowanie HTTP na HTTPS na serwerze lub skonfiguruj CDN, aby laczyc sie z serwerem po HTTPS

• Sprawdz ustawienia wymuszania HTTPS — Jesli masz zarowno przekierowanie na poziomie serwera (Nginx/Apache), JAK I na poziomie CDN wymuszajace HTTPS, usun jedno z nich

• Zweryfikuj naglowek X-Forwarded-Proto — Za proxy Twoj serwer powinien sprawdzac ten naglowek zamiast surowego protokolu polaczenia, aby okreslic, czy oryginalne zadanie bylo HTTPS

Poprawka 3: Napraw petle przekierowan Cloudflare

Cloudflare jest najczestszym zrodlem ERR_TOO_MANY_REDIRECTS ze wzgledu na sposob dzialania jego trybow SSL. Rozwiazanie zalezy od uzytego trybu szyfrowania SSL/TLS.

Rozwiazanie dla 90% petli przekierowan Cloudflare: zmien tryb szyfrowania SSL/TLS z Flexible na Full lub Full (Strict). To informuje Cloudflare, aby laczyc sie z serwerem po HTTPS, eliminujac petle HTTP-HTTPS.

Poprawka Cloudflare krok po kroku

• Krok 1 — Zaloguj sie do panelu Cloudflare

• Krok 2 — Wybierz swoja domene

• Krok 3 — Przejdz do SSL/TLS > Overview

• Krok 4 — Zmien tryb szyfrowania na Full (Strict), jesli masz wazny certyfikat SSL na serwerze, lub Full, jesli masz certyfikat samopodpisany

• Krok 5 — Przejdz do SSL/TLS > Edge Certificates i sprawdz, czy Always Use HTTPS jest wlaczone. Jesli serwer juz przekierowuje na HTTPS, wylacz to, aby uniknac podwojnego przekierowania

• Krok 6 — Sprawdz Page Rules i Redirect Rules pod katem kolidujacych przekierowan URL

• Krok 7 — Wyczysc cache Cloudflare: przejdz do Caching > Configuration > Purge Everything

Poprawka 4: Napraw reguly przekierowan w .htaccess (Apache)

Na serwerach Apache .htaccess to najczestsze miejsce regul przekierowan i najczestsze zrodlo petli przekierowan. Kolidujace reguly, zduplikowane przekierowania lub brakujace warunki moga tworzyc petle.

• Szukaj zduplikowanych przekierowan HTTPS — Jesli panel hostingu (cPanel, Plesk) wymusza HTTPS, usun reczne przekierowanie z .htaccess

• Sprawdz warunki RewriteCond — Kazda regula RewriteRule przekierowujaca powinna miec RewriteCond zapobiegajacy jej uruchomieniu na URL-ach, ktore juz spelniaja warunek. Bez tego regula uruchamia sie przy kazdym zadaniu, wlacznie z juz przekierowanym

• Uwazaj na flage [L] — Flaga [L] oznacza 'ostatnia regula', ale tylko dla biezacego przejscia. Jesli w podkatalogu istnieje inny .htaccess, uruchamia sie ponownie. Uzyj [END] na Apache 2.4+

• Sprawdz naglowki proxy — Za CDN uzyj %{HTTP:X-Forwarded-Proto} zamiast %{HTTPS}, aby wykryc oryginalny protokol

# Correct HTTPS redirect behind Cloudflare/CDN:
RewriteEngine On
RewriteCond %{HTTP:X-Forwarded-Proto} !https
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}/$1 [R=301,L]

Jesli nie jestes pewien, ktora regula powoduje petle, tymczasowo zmien nazwe .htaccess na .htaccess.bak i sprawdz, czy witryna sie laduje. Jesli tak, problem jest w pliku .htaccess. Wlaczaj reguly pojedynczo, az znajdziesz ta problematyczna.

Poprawka 5: Napraw petle przekierowan WordPress

Petle przekierowan w WordPress zazwyczaj pochodza z trzech zrodel: niezgodne URL w ustawieniach, konflikty wtyczek lub nieprawidlowe wartosci w wp-config.php. Jesli nie mozesz dostac sie do panelu WordPress z powodu petli przekierowan, musisz naprawic to bezposrednio przez baze danych lub pliki konfiguracyjne.

Sprawdz ustawienia URL WordPress

WordPress ma dwa ustawienia URL, ktore musza byc zgodne: Adres WordPressa (URL) i Adres witryny (URL) w Ustawienia > Ogolne. Jesli jedno uzywa http://, a drugie https://, lub jedno zawiera www., a drugie nie, otrzymasz petle przekierowan.

Jesli nie mozesz dostac sie do panelu administracyjnego, ustaw adresy URL bezposrednio w wp-config.php:

// Add these lines to wp-config.php (above "That's all, stop editing!"):
define('WP_HOME', 'https://example.com');
define('WP_SITEURL', 'https://example.com');

// If behind a reverse proxy (Cloudflare, Nginx proxy):
if (isset($_SERVER['HTTP_X_FORWARDED_PROTO']) && $_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https') {
    $_SERVER['HTTPS'] = 'on';
}

Wylacz wtyczki, aby znalezc konflikty

Wtyczki przekierowan i buforowania sa czestymi winowajcami. Wtyczki takie jak Redirection, Yoast SEO, Really Simple SSL, WP Super Cache i W3 Total Cache moga dodawac reguly przekierowan kolidujace z konfiguracja serwera lub CDN.

Jesli nie mozesz dostac sie do panelu, wylacz wszystkie wtyczki przez FTP lub SSH:

# Rename the plugins folder to disable all plugins at once:
cd /var/www/html/wp-content/
mv plugins plugins.bak

# If the site loads, rename it back and disable plugins one by one:
mv plugins.bak plugins
# Then rename individual plugin folders to find the culprit:
mv plugins/really-simple-ssl plugins/really-simple-ssl.bak

Jesli wylaczenie wtyczek naprawi blad, wlaczaj je pojedynczo, aby zidentyfikowac kolidujaca wtyczke. Najczesciej winnymi sa wtyczki SSL dodajace przekierowania HTTP na HTTPS, gdy serwer lub CDN juz to obsluguje.

Poprawka 6: Napraw przekierowania na poziomie serwera (Nginx i Apache)

Pliki konfiguracyjne serwera moga zawierac reguly przekierowan kolidujace z przekierowaniami na poziomie aplikacji (WordPress, .htaccess) lub ustawieniami CDN.

Nginx: Szukanie konfliktow przekierowan

Petle przekierowan w Nginx zazwyczaj wystepuja, gdy blok serwera HTTP przekierowuje na HTTPS, ale cos w bloku HTTPS przekierowuje z powrotem na HTTP. Sprawdz konfiguracje witryny:

# Correct Nginx HTTPS redirect (separate server blocks):
server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://example.com$request_uri;
}

server {
    listen 443 ssl;
    server_name example.com;
    # SSL certificate configuration here
    # DO NOT add another redirect to HTTPS here
}

# If behind Cloudflare/proxy, check real protocol:
server {
    listen 80;
    server_name example.com;
    if ($http_x_forwarded_proto != 'https') {
        return 301 https://example.com$request_uri;
    }
}

Apache: Sprawdzanie przekierowan VirtualHost

W Apache sprawdz zarowno konfiguracje VirtualHost, jak i .htaccess. Przekierowanie w konfiguracji VirtualHost plus przekierowanie w .htaccess tworzy podwojne przekierowanie, ktore moze sie zapetlic:

# Check Apache config for redirect rules:
grep -r 'Redirect\|RewriteRule' /etc/apache2/sites-enabled/
grep -r 'Redirect\|RewriteRule' /etc/httpd/conf.d/

# Check .htaccess:
cat /var/www/html/.htaccess | grep -i 'rewrite\|redirect'

Usun zduplikowane przekierowania — zachowaj przekierowanie tylko w jednym miejscu. Najlepsza praktyka to obsluga przekierowan HTTPS w konfiguracji VirtualHost (nie w .htaccess), poniewaz reguly VirtualHost sa przetwarzane raz na zadanie, podczas gdy .htaccess jest przetwarzany przy kazdym zadaniu.

Poprawka 7: Rozwiazywanie problemow specyficznych dla przegladarki

Jesli blad pojawia sie tylko w jednej przegladarce, problem prawdopodobnie dotyczy buforowanego przekierowania lub konfliktu rozszerzenia, a nie serwera.

Chrome: Czyszczenie HSTS i puli gniazd

Chrome buforuje polityki HSTS (HTTP Strict Transport Security) wymuszajace HTTPS. Jesli witryna wczesniej wyslala naglowek HSTS, ale juz nie uzywa poprawnie HTTPS, Chrome bedzie nadal przekierowywal na HTTPS nawet po wyczyszczeniu plikow cookie.

• Wyczysc cache HSTS — Przejdz do chrome://net-internals/#hsts, wpisz domene w polu Delete domain security policies i kliknij Delete

• Oproznij pule gniazd — Przejdz do chrome://net-internals/#sockets i kliknij Flush socket pools, aby wyczyscic buforowane polaczenia

• Wyczysc cache DNS — Przejdz do chrome://net-internals/#dns i kliknij Clear host cache

• Przetestuj w trybie incognito — Otworz okno incognito (Ctrl+Shift+N) i sprobuj otworzyc URL. Jesli w trybie incognito dziala, a w normalnym oknie nie, przyczyna jest buforowane przekierowanie lub rozszerzenie

Poprawki dla Firefox i Safari

Firefox: Wpisz about:config w pasku adresu, wyszukaj network.http.redirection-limit i sprawdz, czy jest ustawiony na 20 (domyslnie). Jesli rozszerzenie zmienilo te wartosc na bardzo mala liczbe, przekierowania moga konczyc sie przedwczesnie. Sprobuj tez usunac dane witryny: Ustawienia > Prywatnosc i bezpieczenstwo > Zarzadzaj danymi > wyszukaj domene > Usun zaznaczone.

Safari: Safari wyswietla "too many redirects occurred" i oferuje mniej szczegolowy blad niz Chrome. Przejdz do Safari > Ustawienia > Prywatnosc > Zarzadzaj danymi witryn, znajdz domene i usun jej dane. Jesli problem nie ustepuje, sprobuj Safari > Wyczysc historie (wybierz cala historie).

Jak zapobiegac petlom przekierowan

Po naprawieniu bledu stosuj te praktyki, aby petle przekierowan nie powtorzyly sie:

• Przekierowuj tylko w jednym miejscu — Wybierz jedna warstwe dla przekierowania HTTPS: CDN, serwer web lub aplikacja. Nigdy nie przekierowuj na kilku warstwach jednoczesnie

• Uzywaj 302 podczas testow — Podczas debugowania uzywaj przekierowan 302 (tymczasowych) zamiast 301 (stalych). Przegladarki agresywnie buforuja 301, co utrudnia testowanie zmian. Przejdz na 301, gdy potwierdzisz poprawne dzialanie

• Zawsze testuj z curl — Po dodaniu reguly przekierowania uruchom curl -ILs https://twojastrona.com | grep -i 'HTTP/\|location:', aby zweryfikowac, ze lancuch przekierowan konczy sie odpowiedzia 200

• Monitoruj narzedziami — Regularnie uzywaj HTTP Headers Checker od DNS Robot, aby sprawdzac, czy witryna zwraca czysta odpowiedz 200 bez nieoczekiwanych przekierowan

• Dokumentuj przekierowania — Prowadz rejestr wszystkich regul przekierowan w konfiguracji serwera, .htaccess, regulach CDN i ustawieniach aplikacji. Gdy kilku czlonkow zespolu zarzadza witryna, nieudokumentowane przekierowania sa przyczyna nr 1 petli

• Czysc cache CDN po zmianach — Po modyfikacji dowolnej reguly przekierowania natychmiast wyczysc cache CDN. Stare buforowane 301 moga utrzymywac sie przez dni

Wplyw petli przekierowan na SEO

Petle przekierowan bezposrednio szkodza Twojemu rankingowi w wyszukiwarkach. Crawler Google (Googlebot) podaza za maksymalnie 10 przekierowaniami na URL, po czym rezygnuje. Jesli Googlebot napotka petle przekierowan, oznacza strone jako blad crawlowania i przestaje ja indeksowac.

Wedlug dokumentacji Google o przekierowaniach, lancuchy przekierowan powinny byc jak najkrotsze. Kazdy dodatkowy skok dodaje okolo 100-500 ms opoznienia i marnuje budzet crawlowania — liczbe stron, ktore Google przeskanuje na Twojej witrynie dziennie.

• Utrata indeksowania — Strony uwiezione w petlach przekierowan nie sa indeksowane i calkowicie znikaja z wynikow wyszukiwania

• Zmarnowany budzet crawlowania — Googlebot zuzywa swoj ograniczony budzet crawlowania na podazanie za przekierowaniami zamiast skanowania rzeczywistej tresci

• Kara za szybkosc strony — Kazde przekierowanie 301 dodaje pelna podroz w obie strony (100-500 ms). Trzy przekierowania moga dodac ponad sekunde do czasu ladowania

• Rozproszenie link equity — Linki zwrotne wskazujace na URL z przekierowaniem traca okolo 1-5% wartosci PageRank na kazdy skok

Czesto zadawane pytania