Podstawowe przyczyny i rozwiązania błędu „Zbyt wiele przekierowań”

Błąd "Too Many Redirects" — wyświetlany w przeglądarkach jako ERR_TOO_MANY_REDIRECTS i odpowiadający pętli przekierowań HTTP — występuje, gdy serwer WWW i klient wchodzą w okrężny łańcuch przekierowań, który nigdy nie prowadzi do ostatecznego miejsca docelowego. Przeglądarka przerywa żądanie po przekroczeniu progu przekierowań (zazwyczaj 20 skoków w Chrome) i wyświetla ten błąd zamiast załadować stronę.

Nie jest to nieokreślona usterka sieciowa. Jest to deterministyczna awaria spowodowana konkretną błędną konfiguracją reguł serwera, ustawień SSL, wartości bazy danych CMS, konfiguracji CDN lub zbuforowanych danych przekierowań. Każdy przypadek ma możliwą do prześledzenia przyczynę źródłową, a każda przyczyna źródłowa ma precyzyjne rozwiązanie. Ten przewodnik omawia wszystkie z nich z techniczną głębią wymaganą do trwałego rozwiązania problemu — niezależnie od tego, czy prowadzisz witrynę WordPress, niestandardową aplikację, czy surowy stos serwerowy w środowisku VPS Hosting.

Co tak naprawdę dzieje się podczas pętli przekierowań

Gdy przeglądarka żąda adresu URL, serwer może odpowiedzieć kodem statusu 301 Moved Permanently, 302 Found lub 307 Temporary Redirect wskazującym nową lokalizację. Przeglądarka podąża za tym nagłówkiem lokalizacji, wysyła kolejne żądanie i oczekuje odpowiedzi 200 OK w pewnym momencie łańcucha.

Pętla przekierowań tworzy się, gdy:

• URL A przekierowuje do URL B, a URL B przekierowuje z powrotem do URL A (pętla dwuskokowa)
• URL A przekierowuje do URL B, który przekierowuje do URL C, który przekierowuje z powrotem do URL A (pętla wieloskokowa)
• Pojedynczy URL przekierowuje do samego siebie (pętla samoreferencji)

Przeglądarki nie zapętlają się w nieskończoność. Chrome i Firefox kończą działanie po około 20 przekierowaniach i wyświetlają ERR_TOO_MANY_REDIRECTS. Safari wyświetla komunikat "Safari Can't Open the Page." Podstawowe zachowanie HTTP jest identyczne we wszystkich z nich.

Przyczyny źródłowe i precyzyjne rozwiązania

1. Błędnie skonfigurowane reguły przekierowań w .htaccess lub Nginx

Najczęstszą technicznie przyczyną są sprzeczne lub okrężne reguły przepisywania w warstwie konfiguracji serwera.

Przykład uszkodzonej pętli w Apache .htaccess:

RewriteEngine On
RewriteRule ^page$ /page [R=301,L]

Ta reguła przekierowuje /page do /page — pętla samoreferencji. Podobnie dwie reguły przekierowujące między /old-url a /new-url w przeciwnych kierunkach spowodują tę samą awarię.

Jak diagnozować:

Otwórz plik .htaccess i ręcznie prześledź każdą dyrektywę RewriteRule i Redirect. Szukaj reguł, w których wzorzec docelowy może pasować do źródła innej reguły.

grep -n "Redirect|RewriteRule|RewriteCond" /var/www/html/.htaccess

W przypadku Nginx równoważny problem pojawia się w blokach server lub location:

# Broken example — loop between two location blocks
location /old {
    return 301 /new;
}
location /new {
    return 301 /old;
}

Przeprowadź audyt konfiguracji Nginx za pomocą:

nginx -T | grep -A3 "return 301|rewrite"

Rozwiązanie: Upewnij się, że każda reguła przekierowania ma unikalne, niepokrywające się źródło i miejsce docelowe. Użyj flagi [L] w Apache, aby zatrzymać przetwarzanie reguł po znalezieniu dopasowania. W Nginx preferuj return 301 zamiast rewrite dla przejrzystości i uniknięcia niezamierzonego łańcuchowania.

2. Błędna konfiguracja przekierowania HTTP na HTTPS

Jest to najczęstsza pojedyncza przyczyna w nowoczesnych środowiskach hostingowych, szczególnie po dodaniu Certyfikatu SSL bez aktualizacji konfiguracji na poziomie aplikacji.

Wzorzec awarii wygląda następująco:

• Serwer WWW wymusza cały ruch HTTP na HTTPS poprzez .htaccess lub konfigurację Nginx
• Aplikacja (np. WordPress) ma opcję siteurl lub home ustawioną na http:// w bazie danych
• Aplikacja następnie przekierowuje żądania HTTPS z powrotem do HTTP
• Pętla wygląda następująco: HTTP → HTTPS (server) → HTTP (app) → HTTPS (server) → ...

Prawidłowe przekierowanie HTTPS w Apache .htaccess:

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

Prawidłowe przekierowanie HTTPS w Nginx:

server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://$host$request_uri;
}

Krytyczna pułapka: Jeśli jesteś za load balancerem lub odwrotnym proxy (w tym Cloudflare), serwer backendowy może nie widzieć HTTPS bezpośrednio. Proxy kończy SSL i przekazuje żądanie jako HTTP do Twojego serwera źródłowego. Twój serwer widzi wtedy %{HTTPS} = off i ponownie przekierowuje do HTTPS — tworząc pętlę.

Rozwiązaniem jest sprawdzenie nagłówka X-Forwarded-Proto:

RewriteEngine On
RewriteCond %{HTTP:X-Forwarded-Proto} =http
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

3. Niezgodność trybu SSL Cloudflare i CDN

Jeśli używasz Cloudflare lub innego CDN przed swoim serwerem źródłowym, tryb szyfrowania SSL/TLS musi odpowiadać rzeczywistemu statusowi certyfikatu Twojego serwera źródłowego.

Najczęstszy scenariusz pętli Cloudflare: Tryb SSL jest ustawiony na Flexible, a serwer źródłowy ma regułę .htaccess wymuszającą HTTP na HTTPS. Cloudflare wysyła HTTP do serwera źródłowego, serwer źródłowy przekierowuje do HTTPS, Cloudflare otrzymuje to przekierowanie, ponownie wysyła HTTP — nieskończona pętla.

Rozwiązanie: Ustaw tryb SSL Cloudflare na Full (Strict) i upewnij się, że Twój serwer źródłowy ma ważny certyfikat. Alternatywnie, jeśli musisz używać trybu Flexible, usuń przekierowanie HTTP→HTTPS z serwera źródłowego i pozwól Cloudflare obsługiwać je za pomocą reguły strony lub przełącznika "Always Use HTTPS".

Wyłącz również Automatic HTTPS Rewrites w Cloudflare, jeśli Twój serwer źródłowy już obsługuje przekierowania — aktywowanie obu podwaja logikę przekierowań.

4. Niezgodność ustawień URL WordPress

WordPress przechowuje swoje kanoniczne adresy URL w dwóch polach bazy danych: siteurl (URL instalacji rdzenia WordPress) i home (publiczny adres URL). Gdy te wartości są sprzeczne z regułami przekierowań serwera lub ze sobą nawzajem, pętla jest niemal nieunikniona.

Sprawdź aktualne wartości przez WP-CLI:

wp option get siteurl
wp option get home

Lub zapytaj bazę danych bezpośrednio:

mysql -u dbuser -p dbname -e "SELECT option_name, option_value FROM wp_options WHERE option_name IN ('siteurl','home');"

Obie wartości muszą używać tego samego protokołu (https://) i tego samego formatu domeny (z lub bez www), który wymusza Twoja konfiguracja serwera.

Rozwiązanie przez WP-CLI:

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

Rozwiązanie przez wp-config.php (nadpisuje wartości bazy danych, przydatne gdy nie masz dostępu do panelu administracyjnego):

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

Konflikty wtyczek: Wtyczki do zarządzania przekierowaniami (Redirection, Simple 301 Redirects, moduł przekierowań Yoast SEO) mogą tworzyć przechowywane w bazie danych reguły przekierowań, które są sprzeczne z regułami na poziomie serwera. Tymczasowo zmień nazwę katalogu wtyczek, aby odizolować problem:

mv /var/www/html/wp-content/plugins /var/www/html/wp-content/plugins_disabled

Ponownie włączaj wtyczki po jednej, po potwierdzeniu, że pętla zniknęła.

5. Pamięć podręczna przeglądarki i zbuforowane przekierowania 301

Przeglądarki agresywnie buforują odpowiedzi 301 Moved Permanently — zgodnie z założeniem. Jeśli przekierowanie 301 było wcześniej serwowane dla adresu URL, a następnie cel przekierowania został zmieniony, przeglądarka może nadal podążać za starym zbuforowanym przekierowaniem, które może wskazywać na teraz zapętlone miejsce docelowe.

Jest to szczególnie mylący scenariusz, ponieważ pętla może nie odtwarzać się w świeżej przeglądarce lub na innym urządzeniu, co prowadzi administratorów do błędnego wniosku, że serwer działa prawidłowo.

Kroki diagnostyczne:

1. Otwórz adres URL w oknie incognito/prywatnym (brak zbuforowanych danych)
2. Przetestuj za pomocą curl, aby całkowicie ominąć buforowanie przeglądarki:

curl -I -L --max-redirs 10 https://example.com

1. Użyj internetowego narzędzia do śledzenia łańcucha przekierowań (np. redirect-checker.org lub httpstatus.io), aby zobaczyć każdy skok po stronie serwera

Rozwiązanie: Wyczyść pamięć podręczną przeglądarki i pliki cookie dla danej domeny. W Chrome: Ustawienia > Prywatność i bezpieczeństwo > Wyczyść dane przeglądania > zaznacz Obrazy i pliki w pamięci podręcznej + Pliki cookie.

W przypadku buforowania po stronie serwera (Varnish, Redis, OPcache lub wtyczka buforowania jak W3 Total Cache):

# Flush Varnish cache
varnishadm ban req.url ~ .

# Flush OPcache via PHP CLI
php -r "opcache_reset();"

6. Konflikty przekierowań www i nie-www

Często pomijanym źródłem pętli przekierowań jest niespójne obsługiwanie subdomeny www. Jeśli Twój serwer przekierowuje www.example.com do example.com i jednocześnie przekierowuje example.com do www.example.com, masz pętlę.

Sprawdź aktualną konfigurację DNS i przekierowań:

curl -sI http://www.example.com | grep -i location
curl -sI http://example.com | grep -i location

Prawidłowa konfiguracja Apache (kanoniczne non-www):

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

Upewnij się, że ta reguła nie jest sparowana z inną regułą, która przekierowuje wersję non-www z powrotem do www.

7. Uszkodzone lub sprzeczne pliki cookie

Niektóre aplikacje używają plików cookie do zarządzania stanem przekierowań (np. przekierowania logowania, wykrywanie ustawień regionalnych, frameworki testów A/B). Jeśli plik cookie przechowuje cel przekierowania, który sam wyzwala kolejne przekierowanie, pętla jest napędzana przez logikę aplikacji, a nie konfigurację serwera.

Diagnoza: Przetestuj adres URL po wyczyszczeniu wszystkich plików cookie dla tej domeny. W Chrome DevTools (F12) przejdź do Application > Storage > Cookies, wybierz domenę i usuń wszystkie wpisy. Przeładuj stronę.

Jeśli błąd znika po wyczyszczeniu plików cookie, problem leży w logice sesji lub przekierowań Twojej aplikacji, a nie w konfiguracji serwera.

Porównanie: Typowe scenariusze pętli przekierowań i ich rozwiązania

Systematyczny przepływ pracy diagnostycznej

Przed dotknięciem jakiegokolwiek pliku konfiguracyjnego postępuj zgodnie z tą sekwencją, aby odizolować przyczynę:

Krok 1 — Odtwórz bez pamięci podręcznej:

curl -v -L --max-redirs 25 https://example.com 2>&1 | grep -E "Location:|< HTTP"

Pokazuje każdy skok przekierowania i końcowy kod odpowiedzi. Jeśli widzisz powtarzające się te same adresy URL, potwierdziłeś pętlę i zidentyfikowałeś, które adresy URL są zaangażowane.

Krok 2 — Sprawdź logi błędów serwera:

# Apache
tail -100 /var/log/apache2/error.log | grep -i redirect

# Nginx
tail -100 /var/log/nginx/error.log | grep -i rewrite

Krok 3 — Odizoluj warstwę:

• Jeśli pętla znika po zakomentowaniu reguł .htaccess, problem leży w konfiguracji Apache
• Jeśli znika po ominięciu Cloudflare (test przez bezpośrednie IP), problem leży w ustawieniach CDN
• Jeśli znika po zmianie nazwy katalogu wtyczek, problem leży we wtyczce WordPress
• Jeśli znika w trybie incognito, ale nie w normalnym trybie, problem leży w pamięci podręcznej przeglądarki lub plikach cookie

Krok 4 — Zweryfikuj powiązanie certyfikatu SSL:

openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | grep -E "subject|issuer|Verify"

Nieprawidłowy lub niedopasowany certyfikat może powodować błędy przekierowania HTTPS, które manifestują się jako pętle.

Zapobieganie pętlom przekierowań w środowisku produkcyjnym

Po rozwiązaniu problemu, te praktyki zapobiegają jego nawrotowi:

• Używaj jednej kanonicznej reguły przekierowania, która obsługuje zarówno HTTP→HTTPS, jak i www→non-www w jednym przebiegu, a nie dwóch oddzielnych reguł, które mogą ze sobą oddziaływać
• Testuj łańcuchy przekierowań przed wdrożeniem za pomocą curl -L lub internetowego narzędzia do sprawdzania przekierowań po każdej zmianie konfiguracji
• Ustawiaj przekierowania 301 tylko gdy są trwałe — używaj 302 podczas testowania, aby przeglądarki nie buforowały przekierowania
• Dokumentuj każdą regułę przekierowania w .htaccess lub konfiguracji Nginx za pomocą komentarzy wyjaśniających intencję
• Monitoruj za pomocą narzędzi do sprawdzania dostępności, które śledzą łańcuchy przekierowań i alertują, gdy liczba skoków przekracza próg

Dla zespołów zarządzających wieloma witrynami na VPS z cPanel, moduł Redirects cPanel zapewnia wizualny interfejs do zarządzania regułami przekierowań, ale zapisuje do .htaccess — zawsze weryfikuj dane wyjściowe ręcznie po użyciu GUI.

Jeśli prowadzisz witrynę o dużym ruchu lub wiele domen, Serwer Dedykowany daje Ci pełną kontrolę nad konfiguracją Nginx lub Apache na poziomie systemu, eliminując ograniczenia środowiska współdzielonego, które mogą komplikować debugowanie przekierowań.

W przypadku witryn korzystających z Paneli Sterowania VPS takich jak Plesk lub DirectAdmin, reguły przekierowań mogą być zarządzane zarówno przez interfejs panelu, jak i bezpośrednio w plikach konfiguracyjnych — sprawdź obie lokalizacje, aby upewnić się, że nie są ze sobą sprzeczne.

Techniczna lista kontrolna kluczowych wniosków

Użyj tego jako listy kontrolnej przed przystąpieniem do diagnozowania ERR_TOO_MANY_REDIRECTS:

• [ ] Uruchom curl -v -L --max-redirs 25, aby zmapować pełny łańcuch przekierowań przed dotknięciem jakiejkolwiek konfiguracji
• [ ] Potwierdź, że zarówno siteurl, jak i home w WordPress odpowiadają protokołowi i domenie wymuszanej przez serwer
• [ ] Zweryfikuj, że tryb SSL Cloudflare to Full (Strict), jeśli Twój serwer źródłowy ma ważny certyfikat
• [ ] Sprawdź, czy konfiguracja .htaccess lub Nginx używa X-Forwarded-Proto zamiast %{HTTPS} za proxy
• [ ] Upewnij się, że przekierowania www i non-www są jednokierunkowe — tylko jedna forma kanoniczna
• [ ] Tymczasowo wyłącz wszystkie wtyczki związane z przekierowaniami i włączaj je ponownie po jednej
• [ ] Wyczyść pamięć podręczną przeglądarki i przetestuj w trybie incognito, aby wykluczyć zbuforowane odpowiedzi 301
• [ ] Sprawdź pliki cookie aplikacji pod kątem stanu przekierowania, który może napędzać pętlę
• [ ] Zweryfikuj, że certyfikat SSL jest ważny i prawidłowo powiązany z domeną
• [ ] Po naprawieniu, tymczasowo użyj 302 przed przełączeniem na 301, aby zapobiec ponownemu zbuforowaniu uszkodzonego przekierowania

FAQ

Jaka jest różnica między ERR_TOO_MANY_REDIRECTS a kodem statusu HTTP 310?

ERR_TOO_MANY_REDIRECTS to błąd po stronie klienta wyzwalany po przekroczeniu przez przeglądarkę limitu śledzenia przekierowań (zazwyczaj 20). HTTP 310 to rzadko używany kod statusu oznaczający "Too Many Redirects" na poziomie protokołu. W praktyce prawie wszystkie błędy pętli przekierowań napotykane w środowisku produkcyjnym to ERR_TOO_MANY_REDIRECTS po stronie przeglądarki — nie odpowiedź 310 wydana przez serwer.

Dlaczego pętla przekierowań pojawia się tylko w niektórych przeglądarkach lub na niektórych urządzeniach, ale nie na innych?

Najczęstszym powodem jest zbuforowane przekierowanie 301 przechowywane w przeglądarce, które wskazuje na teraz nieprawidłowe miejsce docelowe. Ponieważ odpowiedzi 301 są domyślnie buforowane bezterminowo, przeglądarka, która wcześniej odwiedziła adres URL, może podążać za nieaktualnym łańcuchem przekierowań. Testowanie w trybie incognito lub na świeżym urządzeniu omija tę pamięć podręczną i ujawnia aktualne zachowanie serwera.

Jak naprawić pętlę przekierowań w WordPress, gdy nie mogę uzyskać dostępu do panelu administracyjnego?

Dodaj następujące linie bezpośrednio do wp-config.php, aby nadpisać wartości URL w bazie danych, a następnie uzyskaj dostęp do panelu administracyjnego, aby poprawnie skorygować ustawienia:

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

Alternatywnie zaktualizuj wartości bezpośrednio w bazie danych za pomocą wp-cli lub bezpośredniego zapytania MySQL do tabeli wp_options.

Czy pętla przekierowań może wpłynąć na pozycje SEO?

Tak. Pętla przekierowań nie zwraca żadnej odpowiedzi 200 OK, co oznacza, że Googlebot nie może indeksować ani indeksować dotkniętego adresu URL. Jeśli pętla dotyczy Twojej strony głównej lub kluczowych stron docelowych, z czasem doprowadzi do usunięcia z indeksu. Ponadto wszelki kapitał linków 301 przechodzący przez zapętlony adres URL jest skutecznie tracony. Szybkie rozwiązanie pętli i weryfikacja możliwości indeksowania w Google Search Console jest niezbędna.

Jak zapobiec powodowaniu pętli przekierowań przez Cloudflare przy konfiguracji SSL?

Ustaw tryb szyfrowania SSL/TLS Cloudflare na Full (Strict) w panelu SSL/TLS. Zapewnia to, że Cloudflare komunikuje się z Twoim serwerem źródłowym przez HTTPS przy użyciu zweryfikowanego certyfikatu, eliminując pętlę HTTP↔HTTPS, którą tryb Flexible tworzy, gdy serwer źródłowy również wymusza HTTPS. Ponadto wyłącz "Automatic HTTPS Rewrites", jeśli Twój serwer źródłowy lub .htaccess już obsługuje przekierowanie HTTP na HTTPS, aby uniknąć podwójnej logiki przekierowań.