Jak odblokować stronę z błędu „too many redirects”

Błąd too many redirects informuje, że przeglądarka utknęła w pętli odsyłaczy i nigdy nie dociera do docelowej strony. Źródłem bywa jeden drobny zapis w konfiguracji serwera, reguła w CDN, ustawienia URL w CMS lub problem z sesją użytkownika. Ten poradnik przeprowadzi Cię krok po kroku: od szybkiej diagnozy, przez naprawę i testy, po wdrożenie zabezpieczeń, aby pętla nie wróciła. Instrukcje obejmują popularne środowiska – od Apache i Nginx po WordPress, reverse proxy i CDN.

Diagnoza pętli przekierowań

Objawy i szybkie testy lokalne

Zacznij od odtworzenia błędu w kontrolowanych warunkach:

• Otwórz okno prywatne i wejdź na problematyczny adres. Jeśli działa – problemem mogą być cookies lub pamięć przeglądarki.
• Wyczyść dane dla domeny: ustawienia witryn → usuń dane i uprawnienia. Sprawdź na drugim urządzeniu lub innej przeglądarce.
• Odłącz rozszerzenia i reguły blokujące (adblock, privacy) – potrafią generować dodatkowe przekierowania lub zamieniać adresy.
• Spróbuj wariantów adresu: z www i bez, z http i HTTPS, ze slash na końcu i bez. Zapisz, które kombinacje robią pętlę.

Podgląd łańcucha w narzędziach przeglądarki

Włącz DevTools → zakładka Network → odśwież stronę z włączonym logowaniem ruchu. Kliknij pierwszy wpis i sprawdź:

• Headers → Response Headers: Location (dokąd przekierowuje), Status (301/302/307/308), Set-Cookie.
• Headers → Request Headers: Host, Cookie, User-Agent, X-Forwarded-Proto/X-Forwarded-Host, CF-Visitor/True-Client-IP (gdy jest CDN).
• Powtarzający się schemat Location (np. http → https → http) wskazuje na konflikt reguł.

cURL i śledzenie nagłówków

Użyj prostych poleceń, by niezależnie potwierdzić pętlę i zebrać dowody:

• curl -I https://twojadomena.pl – pokazuje tylko nagłówki.
• curl -IL https://twojadomena.pl – z podążaniem za przekierowaniami (kolejne Location).
• curl -I -H „Host: twojadomena.pl” http://IP_SERWERA – sprawdza zachowanie bez DNS/CDN.
• curl -I –resolve twojadomena.pl:443:IP_SERWERA https://twojadomena.pl – kieruje zapytanie bez zmiany produkcyjnego DNS.

Mapa pętli i wskazanie winowajcy

Na podstawie łańcucha Location zbuduj prostą mapę: A → B → C → A. Element, przy którym warunki się zmieniają (np. Host, protokół, ścieżka, ciasteczko) to trop. Typowe wzorce:

• http ↔ https – sprzeczne wymuszanie protokołu w serwerze i w aplikacji.
• non-www ↔ www – dwa różne miejsca próbują kanonizować hosta.
• /strona ↔ /strona/ – pętla znaku końcowego slash.
• /login ↔ / – filtrowanie sesji w aplikacji; ciasteczko sesji nie jest zapisywane (np. domena albo SameSite niepoprawne).
• /sklep ↔ /kategoria – logika aplikacji kieruje do miejsca, które znów prowadzi do źródła.

Sprawdzenie HSTS i pamięci przeglądarki

Polityka HSTS wymusza https i może maskować problem: przeglądarka nie wyśle HTTP nawet, gdy serwer tak oczekuje. Zresetuj HSTS dla domeny (Chrome: chrome://net-internals/#hsts → Delete domain; lub Usuń dane witryny). Jeśli domena jest na liście preload, jedyną drogą jest naprawa certyfikatu/https lub użycie innej subdomeny do testów.

Najczęstsze przyczyny i szybkie poprawki

Konflikty HTTP↔HTTPS i www↔non-www

Najczęstsza pętla: serwer wymusza https i/lub www, a aplikacja robi to samo, ale odwrotnie. Zasada: wymuszanie wykonuj w jednym miejscu, a w drugim wyłącz.

• Wybierz kanoniczny wariant: https + bez www albo https + z www. Zanotuj go i trzymaj się go konsekwentnie.
• Wyłącz duplikaty: jeśli CDN lub WAF (np. Cloudflare) ma regułę Always Use HTTPS, to usuń równoległe przepisy na serwerze lub odwrotnie.
• Unikaj łańcuchów wielostopniowych: www → https → www https. Zamiast dwóch 301 zrób jeden 301 do kanonicznego URL.

Końcowy slash, wielkość liter i języki

Pętle potrafią wynikać z niekonsekwencji w nazewnictwie:

• /sklep → /sklep/ i z powrotem – ujednolić logikę routera (jedna reguła: zawsze ze slashem lub bez).
• Wielkość liter w ścieżkach na systemach Unix ma znaczenie – popraw reguły tak, by nie tworzyły dwóch wariantów.
• Wersje językowe /pl/ ↔ / – pamiętaj o jasnej regule wyboru języka i pamiętaniu go w cookie.

Ustawienia CMS: bazowy adres i URL witryny

W WordPress dwa pola decydują o adresie: Address (URL) i Site Address (URL). Gdy różnią się schematem lub hostem, powstaje pętla. Zaloguj się przez bezpieczny adres serwera (np. tymczasowy host w /etc/hosts) i ustaw spójne wartości. Alternatywnie edytuj wp-config.php i wymuś:

• define(’WP_HOME’,’https://twojadomena.pl’);
• define(’WP_SITEURL’,’https://twojadomena.pl’);

Jeśli panel jest niedostępny, w bazie (tablica options) ustaw siteurl i home. Wtyczki bezpieczeństwa i cache mogą mieć własne przekierowania – dezaktywuj je tymczasowo, zmieniając nazwę katalogu plugins.

Reverse proxy i nagłówki X-Forwarded-Proto

Za proxy (load balancer, ingress) aplikacja często widzi połączenie jako http, choć klient łączy się po https. Wtedy aplikacja próbuje wymusić https, a LB z powrotem robi http do backendu – pętla gotowa. Rozwiązanie: poprawne przekazywanie i interpretacja nagłówków X-Forwarded-Proto/Forwarded oraz konfiguracja, by aplikacja uznała żądanie za https.

• Apache: moduł RemoteIP/SetEnvIfNoCase X-Forwarded-Proto https → ustawia HTTPS=on.
• Nginx jako reverse proxy: proxy_set_header X-Forwarded-Proto $scheme; oraz map dla $http_x_forwarded_proto.
• Frameworki (Symfony, Laravel, Django) mają listę zaufanych pośredników; dodaj IP LB/CDN.

Cloudflare: Flexible SSL i reguły

Tryb Flexible w Cloudflare powoduje https do klienta i http do origin. Jeśli na origin wymusisz https – powstaje pętla. Ustaw Full (strict) z ważnym certyfikatem na serwerze i wyłącz dodatkowe reguły Always Use HTTPS, jeżeli to serwer ma wymuszać. Sprawdź Page Rules/Redirect Rules oraz Transform Rules – jedna sprzeczna kropka w host/URI może uruchomić pętlę.

Logika logowania, SSO i ciasteczka

Jeśli pętla dotyczy /login, podejrzyj ciasteczka sesji: domena, ścieżka, flagi Secure i SameSite.

• Domena: cookie ustawione na .domena.pl nie będzie widoczne na sub2.domena.pl, jeśli blokują to reguły; odwrotnie – cookie na subdomenie nie działa na głównej domenie.
• Secure: przy https cookie musi mieć Secure, inaczej przeglądarka je porzuci i sesja nigdy się nie ustali.
• SameSite: zbyt restrykcyjne (np. Strict) może złamać powrót z SSO/OAuth – ustaw Lax/None (z Secure).
• redirect_uri w OAuth musi dokładnie pasować (schemat, host, ścieżka); drobna różnica wywoła powrotną pętlę 302.

Meta refresh, JavaScript i błędne 301

Rzadziej spotykane, lecz zdradliwe: wstawiony w szablonie meta refresh lub przekierowanie w JS nakłada się na reguły serwera. Usuń je podczas diagnozy. W warstwie serwera używaj trwałego 301 tylko, gdy masz pewność – inaczej utrwalisz złą pętlę w cache przeglądarek i wyszukiwarek.

Poprawa konfiguracji serwera

Apache i plik .htaccess

Wiele pętli w Apache produkuje nieuważne przepisy RewriteRule. Zasady:

• Ustal i sprawdzaj warunki (RewriteCond) zanim przepiszesz. Przykład bezpiecznego wymuszenia https: jeśli HTTPS != on, zrób 301 do https://%{HTTP_HOST}%{REQUEST_URI}.
• Dla kanonizacji www użyj jednej reguły sprawdzającej Host, aby uniknąć przełączeń tam i z powrotem.
• Pamiętaj o flagach [L,R=301,NE] i unikaniu przepisywania już kanonicznych adresów (np. przez warunek %{REQUEST_SCHEME}).
• Gdy masz aplikację w podkatalogu, dbaj o kontekst: base i ścieżki względne.

Jeśli nie jesteś pewien, tymczasowo przenieś .htaccess poza katalog i sprawdź, czy pętla znika. To wskaże, że źródło leży w przepisywaniu. Po diagnozie odtwórz, ale prostszymi regułami.

Nginx: server blocks i mapy

W Nginx trzymaj reguły w osobnych blokach server, by uniknąć konfliktów:

• Blok na port 80: jedna linia return 301 do kanonicznego https-host.
• Blok na 443: obsługa właściwej domeny, bez drugiego wymuszania www/https.
• Używaj map do standaryzacji schematu i hosta, zamiast złożonych if w location.
• Jeśli korzystasz z upstreamu, ustaw proxy_set_header X-Forwarded-Proto i X-Forwarded-Host; upewnij się, że backend rozumie, iż żądanie jest https.

Pętle wynikają też z błędnej kolejności server_name lub wildcardów – konkretniejsze hosty definiuj przed ogólnymi, a domyślny serwer ustaw jako default_server.

Certyfikaty, SNI i HSTS

Zły certyfikat potrafi wywołać niespodziewane zachowanie (np. CDN przekierowuje na inny host). Upewnij się, że cert obejmuje wszystkie warianty (SAN dla www i bez). Jeśli włączasz HSTS, zacznij od krótkiego max-age (np. 300) i bez preload, dopiero po testach zwiększ do docelowego.

Równoważenie obciążenia i sieci

W środowiskach z LB/ingress zapewnij spójność po obu stronach:

• LB wymusza https, backend już nie – i odwrotnie. Jedna warstwa – jeden obowiązek.
• Spójność X-Forwarded-Proto i Forwarded; usuń podwójne lub sprzeczne nagłówki.
• Sticky sessions: przy aplikacjach stanowych błędny rozkład ruchu skutkuje przelogowaniami i pętlą login → home → login.

Cache po drodze: Varnish/CDN

Warstwowy cache może utrwalić zły redirect. W czasie napraw:

• Purge/purge-all w CDN i reverse proxy.
• Włącz tymczasowo bypass dla ścieżek z pętlą.
• Oznaczaj odpowiedzi cache-control: no-store dla stron logowania i sesji.

Kanoniczność adresów

Ustal i stosuj jednolity adres canonical w nagłówkach/HTML. Pamiętaj, że rel=canonical nie zastępuje poprawnej polityki 301 – ale pomaga utrzymać spójność i SEO.

Kroki naprawcze w aplikacjach

WordPress: konfiguracja i wtyczki

WordPress najczęściej zapętla się przez Site URL vs Home URL, wymuszenie https we wtyczce i jednoczesne reguły serwera. Procedura:

• Wymuś adresy w wp-config.php (WP_HOME, WP_SITEURL) zgodne z kanonicznym wariantem.
• Wyłącz wtyczki po kolei (zmiana nazwy katalogów), zacznij od cache, security, redirect managers.
• Włącz tryb debug (WP_DEBUG, WP_DEBUG_LOG) i sprawdź, czy motyw nie wprowadza meta refresh.
• W WooCommerce wyłącz wymuszanie bezpiecznego checkoutu, jeśli serwer już to robi.

Drupal, Joomla i inne CMS

W Drupalu sprawdź base_url, w Joomli – Live Site. Zwróć uwagę na moduły SEF/SEO, które modyfikują linki. Jeden moduł od slasha, drugi od www i zrobisz pętlę – wyłącz i testuj warstwowo.

Frameworki i middleware przekierowań

Laravel: TrustProxies, url()->forceScheme(’https’) oraz APP_URL w .env powinny być spójne z LB/CDN. Symfony: frameworks.trusted_proxies i request_context (scheme/host). Next.js/Nuxt: rewrites/redirects w konfiguracji oraz nagłówki x-forwarded-proto z platform PaaS muszą być uwzględnione. Własne middleware 301/302 – tymczasowo usuń z pipeline i sprawdź efekt.

Sesje, domena ciasteczek i SameSite

Pętle logowania zwykle wskazują na złe parametry sesji:

• Domena ciasteczka: ustaw na .domena.pl, gdy masz subdomeny; unikaj mieszania portów i niestandardowych ścieżek.
• Secure i httpOnly – włączone dla https; bez Secure przeglądarka może odrzucić cookie.
• SameSite=Lax dla zwykłych logowań; dla SSO często potrzebne SameSite=None; Secure.
• Limit czasu sesji – zbyt krótki powoduje ciągłe wylogowania i pętle.

Logika tras i kontrolerów

Przejrzyj warunki w kontrolerach: jeśli użytkownik niezalogowany → /login; a na /login kontroler odsyła zalogowanego → /; ale brak sesji sprawia, że nigdy nie staje się zalogowany. Najpierw upewnij się, że zapis sesji działa (np. katalog na dysku, serwis Redis, uprawnienia), potem uprość przekierowania, dodając twarde warunki anty-pętli (maksymalnie jeden redirect w obrębie żądania).

Procedura awaryjna i prewencja

Szybkie odblokowanie dostępu

Gdy liczy się czas, priorytetem jest przywrócenie dostępności:

• Tymczasowo usuń reguły .htaccess lub zamknij je w komentarzu; w Nginx zastosuj prosty return 200 dla strony statusowej.
• Wyłącz wymuszanie https na warstwie, która powoduje pętlę (np. odznacz Always Use HTTPS w CDN lub usuń redirect w serwerze – zostaw tylko jedną regułę).
• Skieruj DNS na stronę statyczną/maintenance, jeśli nie da się usunąć pętli od ręki.
• W razie HSTS-preload i błędnego certyfikatu – wystaw ważny cert natychmiast na właściwy host; to jedyna skuteczna droga.

Weryfikacja po wdrożeniu

Po wprowadzeniu zmian:

• Purge cache: CDN, WAF, Varnish, cache aplikacji.
• Testy: curl -IL, DevTools Network, testy z innej sieci/urządzenia, Lighthouse.
• Sprawdź statusy: dąż do pojedynczego 301 z niekanonicznego do kanonicznego; reszta żądań 200.

Monitorowanie i alerty

Skonfiguruj monitoring URL: narzędzia uptime z walidacją kodów 3xx i maksymalnej liczby przekierowań. W logach ustaw wzorce alertów na nadmiar 301/302. Zbieraj metryki czasu odpowiedzi – gwałtowne skrócenie wraz ze wzrostem 3xx bywa sygnałem pętli.

Checklist przed produkcją

• Kanoniczny adres spisany: schemat, host, slash.
• Jedno miejsce wymuszania https i www (serwer lub CDN – nie oba naraz).
• Zaufani pośrednicy skonfigurowani; aplikacja rozumie X-Forwarded-Proto.
• Test bez CDN (direct to origin) i bez DNS (resolve/hosts) przeprowadzony.
• Brak meta refresh i ukrytych przekierowań w JS.
• Ciasteczka: domena, Secure, SameSite zgodnie z polityką.
• Brak łańcuchów 301→301; wszędzie pojedynczy skok do wariantu docelowego.

Automatyzacja testów

Dodaj testy e2e (Playwright/Cypress) sprawdzające, że kluczowe adresy nie przekraczają łańcucha 1 przekierowania. W pipeline CI uruchamiaj cURL/Headless i raportuj 3xx. Analizuj logi z grep 301/302, porównując dobowe trendy.

SEO i reputacja

Długotrwała pętla to utrata ruchu i indeksacji. Po naprawie zgłoś ponowne indeksowanie w Search Console. Skontroluj mapę witryny, linki wewnętrzne i nagłówki canonical, aby roboty nie widziały rozjazdów. Zamień tymczasowe 302 na 301 dopiero po pełnej pewności, że trasa jest właściwa.

Dobra dokumentacja zmian

Każdą regułę zapisuj wraz z uzasadnieniem: kto, kiedy i dlaczego. Przyspieszy to przyszłą diagnozę. Ustal wewnętrzną politykę: w którym komponencie wolno wymuszać https/www, gdzie konfigurować redirect i jak testować wpływ nowych wtyczek czy reguł CDN.

Najkrótsza recepta na bezpieczne środowisko to prostota: jeden punkt kanonizacji, przejrzyste reguły na serwerze, świadoma konfiguracja CDN i aplikacji. Z takim zestawem błędy pętli „too many redirects” tracą grunt pod nogami, a Ty zyskujesz przewidywalną infrastrukturę.