Komunikat ERR_TOO_MANY_REDIRECTS to jeden z najbardziej frustrujących błędów, z jakimi może zderzyć się użytkownik oraz administrator strony. Powstaje w momencie, gdy przeglądarka zostaje uwięziona w nieskończonym cyklu żądań, w którym adres docelowy odsyła z powrotem do adresu początkowego. Błąd ten błyskawicznie odcina ruch na stronie i marnuje zasoby crawlera, zmuszając go do wyjścia z zapętlonej witryny.
Zrozumienie mechanizmów odpowiedzialnych za obsługę nagłówków HTTP oraz reguł serwerowych pozwala sprawnie zdiagnozować problem i przywrócić prawidłowe serwowanie treści bez strat w widoczności serwisu.
Najczęściej występujące źródła zapętlenia
Kompilacja pętli przekierowań rzadko wynika z pojedynczego błędu w kodzie. Najczęściej jest to efekt konfliktu dwóch osobnych warstw infrastruktury, z których każda próbuje wymusić własny stan docelowy adresu URL:
- Sprzeczne reguły na serwerze: Błędna konfiguracja w pliku .htaccess lub blokach Nginx, np. jednoczesne wymuszanie adresu z przedrostkiem
wwworaz wariantu bez niego. - Niezgodność szyfrowania SSL / CDN: Użycie trybu Flexible SSL na poziomie proxy przy jednoczesnym wymuszaniu HTTPS na serwerze źródłowym.
- Niewłaściwa konfiguracja adresów w bazie: Niezgodność wartości adresów głównych serwisu w konfiguracji CMS z rzeczywistym adresem wywołania.
- Zła interpretacja nagłówków w aplikacji: Niewłaściwa weryfikacja protokołu w skryptach backendowych, powodująca odsyłanie użytkownika w nieskończoność na ten sam zasób.
Krok 1: Precyzyjna analiza łańcucha przekierowań
Czyszczenie pamięci podręcznej przeglądarki podczas debugowania bywa zdradliwe, ponieważ odpowiedzi ze statusem 301 są agresywnie keszowane lokalnie. Zamiast testować adres w okienku przeglądarki, należy przeanalizować surowe nagłówki odpowiedzi wysyłane przez serwer.
Najbardziej niezawodnym narzędziem diagnostycznym jest wykonanie zapytania w terminalu przy użyciu programu curl z flagami odpytującymi o nagłówki i podążającymi za przekierowaniami:
curl -IL https://twojadomena.plOtrzymana odpowiedź ujawnia każdy krok na ścieżce żądania. Typowy wzorzec pętli wygląda następująco:
HTTP/1.1 301 Moved Permanently
Location: https://twojadomena.pl/
HTTP/1.1 301 Moved Permanently
Location: http://twojadomena.pl/
HTTP/1.1 301 Moved Permanently
Location: https://twojadomena.pl/Dzięki tej weryfikacji łatwo ustalić, czy pętla dotyczy cyklicznej zmiany protokołu (HTTP/HTTPS), czy np. dopisywania ukośnika na końcu adresu (trailing slash).
Przypadek z forum deweloperskiego: Pułapka nagłówka X-Forwarded-Proto
Na forum Stack Overflow opisano przypadek pętli przekierowań, który pojawiał się wyłącznie na środowisku produkcyjnym wykorzystującym odwrotne proxy (reverse proxy). Serwer Cloudflare lub Nginx odbierał bezpieczne połączenie HTTPS od użytkownika, lecz wewnątrz sieci lokalnej przekazywał zapytanie do serwera Apache po portach nieszyfrowanych (HTTP).
W kodzie PHP znajdowała się standardowa kontrola wymuszająca bezpieczne połączenie:
if ($_SERVER['HTTPS'] !== 'on') {
header("Location: https://" . $_SERVER['HTTP_HOST'] . $_SERVER['REQUEST_URI'], true, 301);
exit();
}Ponieważ komunikacja między proxy a serwerem docelowym odbywała się lokalnie po HTTP, zmienna $_SERVER['HTTPS'] nigdy nie zwracała wartości on. Aplikacja bez końca odsyłała przeglądarkę pod adres HTTPS, wywołując pętlę.
Rozwiązaniem tego problemu okazała się weryfikacja nagłówka przekazywanego przez balancery ruchu:
if (isset($_SERVER['HTTP_X_FORWARDED_PROTO']) && $_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https') {
$_SERVER['HTTPS'] = 'on';
}Krok 2: Poprawna konfiguracja reguł w .htaccess i Cloudflare
Aby wyeliminować ryzyko pętli, reguły na poziomie serwera muszą wykluczać się wzajemnie. Warto zadbać o to, aby wymuszenie HTTPS oraz eliminacja prefiksu www odbywały się w jednoznacznie zdefiniowanej kolejności:
RewriteEngine On
# 1. Wymuszenie HTTPS z uwzględnieniem reverse proxy
RewriteCond %{HTTP:X-Forwarded-Proto} !https
RewriteCond %{HTTPS} off
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
# 2. Usunięcie prefiksu WWW (kanoniczny URL)
RewriteCond %{HTTP_HOST} ^www\.(.+) [NC]
RewriteRule ^ https://%1%{REQUEST_URI} [R=301,L]W przypadku korzystania z Cloudflare błąd ten pojawia się najczęściej przy ustawionym trybie szyfrowania Flexible. Jeśli na Twoim serwerze źródłowym istnieje już reguła wymuszająca HTTPS, proxy wpada w pętlę łącząc się z serwerem po HTTP. Przełączenie trybu SSL/TLS na Full lub Full (strict) natychmiast rozwiązuje ten problem.
Optymalizacja przekierowań i wpływ na crawl budget
Każda pętla lub zbyt długi łańcuch przekierowań bezpośrednio przepala crawl budget przydzielony witrynie przez roboty indeksujące. W efekcie roboty mogą zaprzestać dalszego badania strony, zanim dotrą do kluczowych treści.
Kluczem do utrzymania porządku jest stosowanie przemyślanych przekierowań tylko tam, gdzie to konieczne. Jeśli chcesz dokładnie poznać różnice pomiędzy bezwzględnym przeniesieniem zasobu a tymczasową zmianą adresu, zobacz poradnik wyjaśniający, kiedy stosować przekierowanie 301 i 302.