Błąd ERR_TOO_MANY_REDIRECTS: przyczyny i jak go naprawić

ERR_TOO_MANY_REDIRECTS oznacza, że przeglądarka utknęła w pętli przekierowań: serwer odsyła ją z adresu A na adres B i z powrotem na A, aż Chrome lub Firefox poddaje się po 20 skokach. Naprawa prawie zawsze polega na usunięciu jednej z dwóch sprzecznych reguł: trybu Flexible w Cloudflare w połączeniu z wymuszonym przekierowaniem na HTTPS po stronie serwera, niezgodnych adresów strony (http lub https, z www lub bez) w WordPressie i w panelu hostingu albo zdublowanych przekierowań w .htaccess lub Nginx. Odwiedzającym zwykle wystarczy usunąć ciasteczka strony; właściciel strony powinien prześledzić łańcuch poleceniem curl -IL.

Co oznacza błąd i jak pokazują go przeglądarki

Przekierowanie to odpowiedź serwera ze statusem 301, 302, 307 lub 308 i nagłówkiem Location, który wskazuje nowy adres. Jeden lub dwa skoki to norma, na przykład z http://www.example.com na https://example.com. Problem zaczyna się, gdy łańcuch zamyka się w koło albo robi się za długi i przeglądarka przestaje za nim podążać.

Komunikaty podajemy w brzmieniu z angielskiego interfejsu. Przeglądarka w języku polskim pokaże przetłumaczony tekst, ale kod ERR_TOO_MANY_REDIRECTS pozostaje ten sam. Podpowiedź Chrome, by usunąć ciasteczka, nie jest przypadkowa: niektóre pętle wynikają z ciasteczek. Strona sprawdza język, region lub stan logowania i w kółko odsyła cię na tę samą stronę.

Szybkie rozwiązania dla odwiedzających

• Otwórz stronę w oknie incognito lub prywatnym (Ctrl+Shift+N w Chrome, Ctrl+Shift+P w Firefoksie). Jeśli tam działa, przyczyna leży w twoich ciasteczkach lub pamięci podręcznej.
• Usuń ciasteczka tylko tej strony: w Chrome kliknij ikonę po lewej stronie paska adresu, otwórz sekcję plików cookie i danych witryny i usuń dane strony.
• Wyczyść obrazy i pliki zapisane w pamięci podręcznej (Ctrl+Shift+Delete). Przeglądarki zapamiętują przekierowania 301 i mogą odtworzyć stare przekierowanie, nawet gdy właściciel już je poprawił.
• Wyłącz rozszerzenia, które przepisują adresy URL: VPN, proxy, blokery reklam i dodatki wymuszające HTTPS.
• Sprawdź stronę na telefonie przez transmisję danych. Jeśli błąd pojawia się wszędzie, problem leży po stronie witryny: podaj właścicielowi godzinę i dokładny adres URL.

Najczęstsze przyczyny pętli przekierowań

Pętla prawie zawsze powstaje z dwóch reguł, które ciągną adres w przeciwne strony:

Osobną pułapką są przekierowania z pamięci podręcznej: przeglądarka zapamiętuje odpowiedzi 301, wtyczka cache lub CDN może podać zapisaną odpowiedź, a HSTS sprawia, że przeglądarka sama przełącza się na HTTPS. Dlatego każdą poprawkę sprawdzaj w oknie prywatnym albo przez curl.

Jak prześledzić łańcuch przekierowań

Nie zgaduj, tylko sprawdź, dokąd naprawdę odsyła cię serwer. curl jest dostępny w Linuksie, macOS i Windows 10/11 (w PowerShell wpisz curl.exe):

curl -sSIL --max-redirs 10 http://example.com/ | grep -iE "^(HTTP|location|server)"

Typowa pętla z Cloudflare w trybie Flexible:

HTTP/1.1 301 Moved Permanently
Location: https://example.com/
HTTP/2 301
location: https://example.com/
server: cloudflare
HTTP/2 301
location: https://example.com/
server: cloudflare
...
curl: (47) Maximum (10) redirects followed

Jeśli Location wciąż powtarza adres, o który prosisz, serwer przekierowuje sam na siebie. server: cloudflare oznacza, że odpowiedź przechodzi przez Cloudflare, więc sprawdź tryb szyfrowania. Naprzemienne http/https albo www/bez www pokazują, które dwie reguły się ze sobą biją. Aby sprawdzić serwer źródłowy z pominięciem Cloudflare, przypisz domenę do adresu IP swojego serwera:

curl -sSIL --max-redirs 10 --resolve example.com:443:203.0.113.10 https://example.com/

W przeglądarce otwórz DevTools (F12), przejdź do karty Network, włącz Preserve log i odśwież stronę. Każdy wiersz z kodem 301, 302, 307 lub 308 to jeden skok. Przekierowanie 307 Internal Redirect z nagłówkiem Non-Authoritative-Reason: HSTS tworzy sama przeglądarka z powodu zapisanej polityki HSTS, a nie serwer.

Jak naprawić ERR_TOO_MANY_REDIRECTS w Cloudflare

W trybie Flexible Cloudflare przyjmuje odwiedzającego przez HTTPS, ale z twoim serwerem łączy się zwykłym, nieszyfrowanym HTTP. Jeśli serwer wymusza HTTPS (ustawienie w panelu, .htaccess, Nginx lub wtyczka WordPressa), odpowiada przekierowaniem na https://. Cloudflare przekazuje je przeglądarce, przeglądarka wraca przez HTTPS, a Cloudflare znowu łączy się z serwerem przez HTTP. Dokumentacja Cloudflare wymienia ten scenariusz jako pierwszą przyczynę ERR_TOO_MANY_REDIRECTS.

1. Upewnij się, że serwer źródłowy ma ważny certyfikat (zobacz nasz poradnik o certyfikacie SSL na hostingu współdzielonym). W panelu sterowania hostingu darmowy certyfikat Let’s Encrypt zwykle wystawisz w kilka minut w ustawieniach domeny.
2. W Cloudflare otwórz SSL/TLS → Overview → Configure i wybierz Full (strict). Zwykły tryb Full jest przeznaczony tylko dla certyfikatu samopodpisanego na serwerze.
3. Jeśli strefa korzysta z Automatic SSL/TLS, sprawdź, jaki tryb jest faktycznie stosowany, i w razie potrzeby przełącz na Custom SSL/TLS.
4. Przejrzyj Rules: Redirect Rules i starsze Page Rules nie mogą być sprzeczne z serwerem (na przykład Cloudflare kieruje na www, a serwer usuwa www).
5. Wyczyść cache (Caching → Configuration → Purge Everything), jeśli buforujesz HTML. Bez nagłówków cache Cloudflare domyślnie przechowuje odpowiedź 301 do 120 minut.

Zdarza się też odwrotna sytuacja: tryb Full, a serwer lub WordPress przekierowuje z HTTPS na HTTP. Usuń to przekierowanie i popraw adres strony. Opcja Always Use HTTPS (SSL/TLS → Edge Certificates) jest bezpieczna w każdym trybie, o ile nic na serwerze nie odsyła odwiedzających na http. Szerszy kontekst znajdziesz w artykule o tym, kiedy CDN się opłaca, a kiedy nie.

WordPress: adres strony, wtyczki i wp-config.php

WordPress przekierowuje odwiedzających na wartości „Adres WordPressa (URL)” i „Adres witryny (URL)”, zapisane jako siteurl i home w tabeli wp_options. Jeśli jest tam http://example.com, a serwer wymusza HTTPS, albo www.example.com, a panel usuwa www, powstaje pętla. Sprawdź i popraw je przez WP-CLI:

wp option get home
wp option get siteurl
wp option update home 'https://example.com'
wp option update siteurl 'https://example.com'

Nie masz dostępu do kokpitu ani SSH? Ustaw adres w wp-config.php powyżej /* That's all, stop editing! */. Te stałe nadpisują wartości z bazy danych:

define( 'WP_HOME', 'https://example.com' );
define( 'WP_SITEURL', 'https://example.com' );

Za własnym reverse proxy lub load balancerem PHP widzi zwykłe HTTP, a WordPress z FORCE_SSL_ADMIN lub wtyczką SSL ciągle przekierowuje. Dokumentacja WordPressa zaleca uwzględnienie X-Forwarded-Proto; dodaj ten kod powyżej require_once ABSPATH . 'wp-settings.php';:

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

Przy Cloudflare czystszym rozwiązaniem jest przełączenie na Full (strict). Drugim typowym podejrzanym są wtyczki: wtyczki SSL (na przykład Really Simple Security), menedżery przekierowań, wtyczki wielojęzyczne, cache stron i wtyczki bezpieczeństwa, które przenoszą stronę logowania. Wyłącz wszystkie, sprawdź, a potem włączaj je po kolei:

wp plugin deactivate --all
# no SSH: rename wp-content/plugins to plugins-off in the file manager
wp search-replace 'http://example.com' 'https://example.com' --skip-columns=guid --dry-run

Bez SSH zmień w menedżerze plików nazwę katalogu wp-content/plugins na plugins-off. Ostatnie polecenie pokazuje podgląd zamiany starych adresów http po przejściu na HTTPS; usuń --dry-run, aby ją wykonać. Pętla z ukośnikiem na końcu (/page/ i /page) oznacza, że reguła serwera jest sprzeczna ze strukturą bezpośrednich odnośników, więc zostaw tylko jedną z nich.

Reguły serwera: .htaccess, Nginx i panel sterowania

Apache .htaccess

Klasyczny błąd to reguła bez warunku, która przekierowuje nawet żądania przychodzące już przez HTTPS. Ta wersja sprawdza protokół i host oraz załatwia http i www w jednym skoku (cel bez www). Umieść ją przed # BEGIN WordPress:

RewriteEngine On
RewriteCond %{HTTPS} !=on [OR]
RewriteCond %{HTTP_HOST} ^www\. [NC]
RewriteCond %{HTTP_HOST} ^(?:www\.)?(.+)$ [NC]
RewriteRule ^ https://%1%{REQUEST_URI} [L,R=301]

Jeśli Apache stoi za proxy, które kończy połączenie HTTPS, zmienna HTTPS zawsze ma wartość off. Przekierowuj wtedy tylko żądania, które nie przyszły przez HTTPS ani bezpośrednio, ani przez proxy:

RewriteCond %{HTTPS} !=on
RewriteCond %{HTTP:X-Forwarded-Proto} !https
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

Nginx

Przekierowanie na HTTPS powinno być tylko w bloku server nasłuchującym na porcie 80. Pętla pojawia się, gdy return 301 trafi do bloku listen 443 albo do wspólnego bloku nasłuchującego na obu portach:

server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://example.com$request_uri;
}
server {
    listen 443 ssl;
    server_name www.example.com;
    ssl_certificate     /etc/ssl/example.com.crt;
    ssl_certificate_key /etc/ssl/example.com.key;
    return 301 https://example.com$request_uri;
}
server {
    listen 443 ssl;
    server_name example.com;
    ssl_certificate     /etc/ssl/example.com.crt;
    ssl_certificate_key /etc/ssl/example.com.key;
    root /var/www/example.com;
    # rest of the site config
}

Wyszukanie istniejących przekierowań oraz sprawdzenie i przeładowanie konfiguracji po zmianie:

sudo grep -RnE "return 30[1278]|rewrite .* (permanent|redirect)" /etc/nginx/
sudo nginx -t && sudo systemctl reload nginx

Za Cloudflare Flexible lub load balancerem warunek if ($scheme = http) jest zawsze prawdziwy. Sprawdzaj zamiast tego $http_x_forwarded_proto albo, co lepsze, przełącz Cloudflare na Full (strict).

Panel sterowania hostingu

• Automatyczne przekierowanie na HTTPS w wielu panelach zapisuje return 301 https://$host$request_uri; tylko w bloku HTTP, więc sama ta opcja nie stworzy pętli. Pętla powstaje dopiero w połączeniu z Cloudflare Flexible.
• Przekierowanie domeny wymusza wersję z www lub bez. Musi zgadzać się z adresem w WordPressie.
• HSTS (HTTP Strict Transport Security) zwykle wysyła max-age=31536000, więc przeglądarki przez rok pamiętają, że strona działa tylko przez HTTPS. Włącz tę opcję, gdy HTTPS działa stabilnie.

Jak zapobiegać pętlom i chronić SEO

• Jedna reguła na jedno zadanie. Ustaw HTTPS i wybór wersji z www lub bez w jednym miejscu; WordPress ma się tylko do tego dopasować.
• Jeden skok, a nie łańcuch. http://www.example.com powinien prowadzić prosto na https://example.com. Google podąża za maksymalnie 10 skokami, a każdy dodatkowy skok wydłuża czas ładowania.
• Testuj z 302, wdrażaj z 301. Przeglądarki zapamiętują odpowiedzi 301, więc błędna reguła stała przetrwa poprawkę.
• HSTS włączaj na końcu, gdy HTTPS działa na wszystkich używanych nazwach hostów.
• Planuj migracje. Rozpisz przekierowania przed przeprowadzką; zobacz nasze wskazówki o migracji hostingu bez strat.

FAQ

Dlaczego błąd pojawia się tylko w jednej przeglądarce?

Zwykle z powodu ciasteczek, zapamiętanego przekierowania 301 albo zapisanej polityki HSTS. Jeśli strona działa w oknie prywatnym, usuń jej dane. W Chrome wpis HSTS usuniesz na stronie chrome://net-internals/#hsts w sekcji Delete domain security policies.

Dlaczego błąd pojawił się zaraz po włączeniu Cloudflare?

Prawie zawsze winny jest tryb Flexible: Cloudflare łączy się z serwerem przez HTTP, a serwer odsyła odwiedzających z powrotem na HTTPS. Zainstaluj certyfikat na serwerze i wybierz Full (strict).

Jak wejść do wp-admin, jeśli tam też jest pętla?

Skorzystaj z menedżera plików w panelu lub z FTP: zdefiniuj WP_HOME i WP_SITEURL w wp-config.php i zmień nazwę katalogu wp-content/plugins. Zaloguj się, popraw adresy w Ustawienia → Ogólne, a potem przywróć katalog wtyczek.

Czy ERR_TOO_MANY_REDIRECTS szkodzi SEO?

Googlebot nie może pobrać strony, więc Search Console zgłasza błąd przekierowania. Krótka awaria nie zaszkodzi; pętla trwająca tygodniami może wypchnąć strony z indeksu.

Przekierowanie na HTTPS: 301 czy 302?

Do stałej zmiany adresu używaj 301 (lub 308). Podczas testów używaj 302, bo przeglądarki nie przechowują go długo w pamięci podręcznej.

Podsumowanie

ERR_TOO_MANY_REDIRECTS zawsze oznacza, że dwie reguły są ze sobą sprzeczne. Prześledź łańcuch poleceniem curl, ustal, kto przekierowuje (Cloudflare, serwer czy WordPress), i zostaw dokładnie jedną regułę dla HTTPS i jedną dla www. Większość przypadków rozwiązuje przełączenie Cloudflare na Full (strict) lub poprawienie adresu w WordPressie. W pakietach hostingu współdzielonego RichHost certyfikat Let’s Encrypt jest darmowy, a domeną zarządzasz we własnym panelu sterowania z asystentem AI, więc Cloudflare Full (strict) ma na serwerze ważny certyfikat.