Przejdź do treści 
W zwięzły i jasny sposób wyjaśnię, w jaki sposób można stworzyć Pętla przekierowań WordPress oraz rzetelnie je przeanalizować i rozwiązać. Pokażę ci natychmiastowe rozwiązania konfliktów SSL, błędnych reguł .htaccess, nieprawidłowych adresów URL witryny, buforowania / plików cookie, problemów z wtyczkami i ustawień serwera - w tym testy i zapobieganie.
Punkty centralne
Poniższa lista podsumowuje najważniejsze kroki, zanim wyjaśnię je szczegółowo.
- Przyczyna szybko zawęzić: SSL, .htaccess, adresy URL, wtyczki, pamięć podręczna
- Standard-Sprawdź reguły: .htaccess i wp-config.php
- HTTPS ustawione prawidłowo: Certyfikat, Zawartość mieszana, HSTS
- Wtyczki Wyłączanie testowe: za pośrednictwem pulpitu nawigacyjnego lub FTP
- Zapobieganie ustanowienie: Kopie zapasowe, dokumentacja, monitorowanie
Co właściwie oznacza pętla przekierowania?
A Pętla przekierowania występuje, gdy URL A przeskakuje do URL B, a B przeskakuje z powrotem do A - lub gdy kilka przeskoków prowadzi z powrotem do adresu początkowego na końcu. Przeglądarka anuluje wtedy z ERR_TOO_MANY_REDIRECTS i blokuje połączenie. Często rozpoznaję pętlę po tym, że logowanie ponownie ładuje formularz logowania po poprawnym wprowadzeniu. Dla odwiedzających wygląda to jak niekończąca się runda, dla wyszukiwarek jak błąd techniczny. Kosztuje to zaufanie, uniemożliwia logowanie do zaplecza i pochłania cenne budżety indeksowania.
Główne przyczyny pętli w WordPress
Znajduję najczęstsze wyzwalacze w fałszywy Adresy URL WordPress, agresywne reguły .htaccess, podwójne wymuszenia SSL lub chaotyczne przekierowania wtyczek. Stare pliki cookie i twarde pamięci podręczne przeglądarki również wysyłają żądania na manowce. Po zmianie domeny lub konwersji HTTPS błędy występują częściej, ponieważ http i https są mieszane. W motywach z własnymi przekierowaniami lub wtyczkami bezpieczeństwa reguły mogą się wzajemnie blokować. W rzadkich przypadkach złośliwe oprogramowanie celowo ustawia przekierowania, aby zablokować administratorów.
Szybkie testy w przeglądarce: Pliki cookie i pamięć podręczna
Zaczynam od Klient-check, ponieważ przynosi jasność w ciągu kilku minut. Usuwam pliki cookie i całą pamięć podręczną dla dotkniętej domeny. Prywatne okno pomaga wykluczyć stare sesje. Jeśli logowanie następnie działa, było to spowodowane danymi lokalnymi, a nie serwerem. Jeśli błąd nadal występuje, przechodzę do poziomu serwera i WordPressa.
Sprawdź .htaccess i przywróć ustawienia domyślne
Zabezpieczam htaccess i zresetować je do standardu WordPress jako test. W ten sposób usuwam sprzeczne przekierowania z poprzednich eksperymentów lub reguł SEO.
# BEGIN WordPress
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
# END WordPress
Gdy wszystko będzie już działało, dodam dodatkowe przekierowania krok po kroku. Dla czystych warunków odsyłam do przekierowania htaccess z praktycznymi przykładami. Ważne: Nigdy nie wymuszaj http→https dwukrotnie - wystarczy raz na poziomie serwera.
Dostosowywanie adresów URL WordPress w ustawieniach i wp-config.php
Odchylenia pomiędzy WP_HOME i WP_SITEURL często powodują niekończące się pętle, szczególnie po przeniesieniu domeny. Najpierw sprawdzam Ustawienia > Ogólne. Jeśli backend nie jest dostępny, krótko ustawiam wartości w wp-config.php:
define( 'WP_HOME', 'https://deinedomain.de' );
define( 'WP_SITEURL', 'https://deinedomain.de' );
W przypadku problemów administratora z SSL, również tymczasowo odblokowuję dostęp:
define('FORCE_SSL_ADMIN', false);
Jak tylko jestem w dashboardzie, ustawiam poprawne adresy URL i ponownie usuwam stałe. Znormalizowane adresy zapobiegają powtarzającym się pętlom.
Czyste rozwiązywanie konfliktów HTTPS/SSL
Konflikty pojawiają się, gdy SSL jest wymuszany po stronie serwera, a wtyczka ustawia również przekierowania. Najpierw sprawdzam, czy certyfikat jest ważny i czy nagłówki HSTS lub proxy zakłócają rozpoznawanie. Następnie upewniam się, że istnieje wyraźna lokalizacja, która wymusza https - najlepiej na poziomie serwera. Konsekwentnie eliminuję błędy mieszanej treści i nieprawidłowe łańcuchy przekierowań. Jeśli chodzi o faktyczną zmianę, ten przewodnik pomaga mi Konwersja HTTPS w WordPress.
Ograniczanie wtyczek i motywów jako źródło błędów
Włączam podejrzliwość Wtyczki zwłaszcza przekierowania, SEO i narzędzia bezpieczeństwa. Jeśli nie mogę dostać się do zaplecza, zmieniam nazwę folderu wp-content/plugins na plugins.old przez FTP. Następnie aktywuję każdą wtyczkę indywidualnie na pulpicie nawigacyjnym, aż błąd pojawi się ponownie. Przełączenie na standardowy motyw, taki jak Twenty Twenty-Four, pokazuje również, czy motyw generuje reguły. Pozwala mi to szybko znaleźć przyczynę i stworzyć konfigurację wolną od konfliktów.
Koniec pętli logowania: Pliki cookie, sesje, bezpieczeństwo
Jeśli logowanie nie powiedzie się pomimo poprawnego Dane przeskakuje ponownie, sprawdzam domenę plików cookie, ścieżkę i flagę https. Czyszczę pamięć podręczną na wszystkich poziomach: Przeglądarka, WordPress cache, object cache, CDN. W przypadku wtyczek bezpieczeństwa sprawdzam reguły, które przekierowują adresy URL administratora lub ograniczają logowanie. Tymczasowo ustawiam czyste wartości domyślne do diagnostyki, a następnie odbudowuję zabezpieczenia krok po kroku. Cel: stabilna sesja bez zduplikowanych przekierowań.
Prawidłowe ustawienie odwrotnego proxy, CDN i nagłówka serwera
Za Pełnomocnik Aplikacje łatwo mylą http i https, jeśli brakuje nagłówka Forwarded lub X-Forwarded-Proto lub jest on nieprawidłowy. Sprawdzam konfiguracje Nginx/Apache, ustawienia load balancera i przekierowania CDN. Ważne jest, aby WordPress poprawnie rozpoznawał rzeczywisty adres URL klienta. W przypadku konfiguracji z proxy upstream, ten przewodnik pomaga mi Konfiguracja odwrotnego serwera proxy. Zapobiega to sprzecznym regułom między serwerem, CDN i wtyczką.
Złośliwe oprogramowanie jako ostateczne źródło podejrzeń
Jeśli pętla nadal może zostać zamknięta pomimo wszystkich poprawek nie Skanuję instalację w poszukiwaniu złośliwego kodu. Porównuję podstawowe pliki z oryginałami, sprawdzam nowszych administratorów i zadania cron. Ujawniam przekierowania w nagłówkach, plikach szablonów lub za pośrednictwem JavaScript, wyszukując window.location, meta refresh lub niejasne ciągi Base64. Po wyczyszczeniu resetuję hasła i tworzę nową kopię zapasową. Zabezpieczenie przed ponowną infekcją oszczędza później mnóstwo czasu.
Profilaktyka i monitorowanie w życiu codziennym
Zapobiegam pętlom poprzez Zmiany Centralnie zarządzam przekierowaniami i testuję je w środowisku przejściowym przed wdrożeniem na żywo. Automatycznie tworzę kopie zapasowe i aktualizuję wtyczki i motywy. Po zmianie domeny sprawdzam adresy URL witryny, SSL i łańcuchy przekierowań. Mały system monitorowania powiadamia mnie o skokach kodu stanu na wczesnym etapie. Poniższa tabela pomaga w szybkiej diagnostyce podczas pracy.
| Objaw | Możliwa przyczyna | Bezpośredni pomiar | Narzędzie testowe |
|---|---|---|---|
| ERR_TOO_MANY_REDIRECTS | Podwójne egzekwowanie https | Używaj tylko jednej lokalizacji dla przekierowań | Sprawdzanie nagłówków HTTP, Curl |
| Logowanie powraca | Konflikt plików cookie/sesji | Usuń pliki cookie, opróżnij pamięć podręczną | Okno prywatne, DevTools |
| Strona główna nie ładuje się | Pętla .htaccess | Aktywuj standardowy .htaccess | Dzienniki serwera, diff |
| Wadliwe tylko w ramach proxy | Nieprawidłowy nagłówek Proto | Prawidłowe ustawienie X-Forwarded-Proto | Proxy-Config, Header-Trace |
| Nagle z rankingu | Łańcuchy przekierowań | Redukcja łańcuchów, 301 poprawnych | Crawler, Screaming Frog |
Precyzyjne śledzenie przekierowań: Śledzenie nagłówków i curl
Zanim przejdę do konfiguracji, narysuję dokładny łańcuch do. W DevTools (zakładka Network) można zobaczyć każdy przeskok z kodem statusu i nagłówkiem lokalizacji. Na powłoce jest to często wystarczające:
curl -IL https://deinedomain.de
# lub szczegółowe z wyświetlaniem każdego przekierowania
curl -IL --max-redirs 20 https://deinedomain.de
Zwracam uwagę na wzorce takie jak http→https→http (tam i z powrotem) lub www↔non-www. 302 następujące po 301 jest również podejrzane. Jeśli nawet pierwsze żądanie przekierowuje do /wp-login.php, przyczyną jest zwykle wtyczka / motyw lub pliki cookie; jeśli dzieje się to globalnie, często jest to .htaccess lub serwer.
Ukierunkowane wykorzystanie logów serwera i WordPressa
Dzienniki oszczędzają godziny. Aktywuję dziennik debugowania w wp-config.php bez wyświetlania go odwiedzającym:
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);
@ini_set('display_errors', 0);
Następnie sprawdzam /wp-content/debug.log pod kątem wskazówek (np. "Cannot modify header information" przed przekierowaniem). Jednocześnie sprawdzam dzienniki serwera WWW. Dla Apache: access.log i error.log, dla Nginx: access.log ze statusem 301/302. Spojrzenie na agenta użytkownika pomaga określić, czy dotyczy to tylko botów, czy wszystkich użytkowników.
WP-CLI: szybki ratunek przez konsolę
Jeśli pulpit nawigacyjny nie jest dostępny, wiele rzeczy rozwiązuję za pomocą WP-CLI:
# Sprawdzanie i ustawianie adresów URL
wp option get home
wp option get siteurl
wp option update home 'https://deinedomain.de'
wp option update siteurl 'https://deinedomain.de'
# "Zapisz przez" permalinki raz
wp rewrite flush --hard
# Opróżnianie pamięci podręcznej
wp cache flush
wp transient delete --all
# Masowa dezaktywacja / testowanie wtyczek
wp plugin deactivate --all
wp plugin activate classic-editor
W ten sposób mogę wrócić do systemu bez ryzyka, znaleźć winowajców i aktywować tylko to, co jest naprawdę potrzebne.
www, ukośnik i kanonizacja bez pętli
Pętle są często tworzone z drobne niespójnościwww vs. nie-www, brak/dodatkowy slash lub mieszane proto. Decyduję się na jeden wariant i ustawiam tylko a Łańcuch reguł. Przykład nie-www→www w Apache (bez podwójnego wymuszenia https):
RewriteEngine On
# Przekazuj tylko jeśli host nie jest jeszcze www
RewriteCond %{HTTP_HOST} !^www\. [NC]
RewriteRule ^(.*)$ https://www.%{HTTP_HOST}/$1 [L,R=301]
W przypadku Nginx ustawiam wyraźne przekierowanie blokady serwera i unikam mieszanych reguł w PHP/wtyczkach. Ważne: najpierw kanonizacja (www/slash), potem https - i tylko do a Stanowisko.
Czyszczenie za proxy/CDN: Prawidłowe rozpoznawanie HTTPS
Jeśli WordPress znajduje się za load balancerem lub CDN, backend często odbiera tylko http, chociaż klient używa https. WordPress nieprawidłowo rozpoznaje wtedy is_ssl() i generuje pętle. Poprawiam zmienne serwera wcześnie w wp-config.php:
if (isset($_SERVER['HTTP_X_FORWARDED_PROTO']) && $_SERVER['HTTP_X_FORWARDED_PROTO'] == 'https') {
$_SERVER['HTTPS'] = 'on';
}
Ustawiłem również nagłówki X-Forwarded-Proto i Forwarded clean na serwerze proxy. HSTS używam oszczędnie: Jeśli HSTS jest aktywny, może brak http, w przeciwnym razie przeglądarka zawiesza się. Używam preload tylko wtedy, gdy wszystkie subdomeny działają stabilnie na https.
Usuwanie pułapek związanych z logowaniem i plikami cookie
Częstym źródłem są nieprawidłowo ustawione pliki cookie. Zazwyczaj ustawiam brak COOKIE_DOMAIN. Jeśli został już raz zdefiniowany, zmieniam go jako test:
define('COOKIE_DOMAIN', false);
Sprawdzam również, czy flaga plików cookie administratora "Secure" jest ustawiona pod https, a ścieżka jest ustawiona na "/". W przypadku uporczywych problemów usuwam sesje po stronie serwera (np. restartując php-fpm) i opróżniam pamięć podręczną obiektów/redis, aby stare nonces przestały działać.
Cechy szczególne mapowania wielu witryn i domen
Na stronie Multisite-Konfiguracje, różne mapowania szybko prowadzą do pętli: Subdomena vs. tryb katalogu, różne protokoły lub stara wtyczka mapowania domeny z własnymi przekierowaniami. Sprawdzam tabele bloga i witryny, synchronizuję protokoły i hosty oraz na krótko dezaktywuję automatyczne przekierowania w celu zmiany języka. Logowanie "Super Admin" na głównym blogu pomaga centralnie zobaczyć przekierowania sieciowe. Ważne: tylko jedna instancja decyduje o domenie kanonicznej.
WooCommerce, wielojęzyczność i "Ukryj logowanie"
Sklepy i witryny wielojęzyczne mają dodatkowe logiki przekierowań: wymuszone strony SSL (kasa/konto), przekierowanie języka na Accept-Language lub funkcje "Hide Login" we wtyczkach bezpieczeństwa. W celu diagnozy dezaktywuję automatyczne przekierowanie języka i tymczasowo zezwalam na /wp-login.php bez przekierowania. W WooCommerce ustawiam "Tylko te strony na SSL" albo czysto po stronie serwera, albo całkowicie systemowo, aby nie występowały stany mieszane.
Pamięć podręczna obiektów współrzędnych, kod operacyjny i pamięć podręczna krawędzi
Kilka warstw buforowania może siebie nawzajem amplify: PHP opcode (OPcache), object cache (Redis/Memcached), page cache wtyczek i CDN edge. Opróżniam je w uporządkowanej kolejności, aby żadna warstwa nie zwracała starych przekierowań. Po zmianie reguł całkowicie unieważniam pamięć podręczną krawędzi. Dopiero wtedy test ma sens.
Typowe pułapki Nginx
W przypadku Nginx pętle występują, gdy bloki lokalizacji są przepisywane dwukrotnie lub /index.php działa wewnętrznie i zewnętrznie. Używam jednej czystej konfiguracji: najpierw przekierowanie bloku serwera (www/https), a następnie czysty try_files na /index.php. Konsekwentnie unikam mieszanek odświeżania add_header i 301/302.
Lista kontrolna: znajdź przyczynę w 10 minut
- Usuń pliki cookie / pamięć podręczną lokalnie, przetestuj w trybie incognito
- uruchom curl -IL i wyświetl łańcuch
- Zresetuj .htaccess/Nginx do domyślnej ścieżki
- Synchronizacja WP_HOME/WP_SITEURL (w razie potrzeby za pośrednictwem WP-CLI)
- Tylko jedna instancja wymusza https (preferowany serwer)
- Dezaktywacja wtyczek/tematu, aktywacja krok po kroku
- Poprawnie ustaw nagłówek proxy, sprawdź is_ssl()
- Pusta pamięć podręczna obiektu/strony/krawędzi
- Sprawdź dzienniki: debug.log, access/error.log
- Funkcje specjalne: Multisite, Woo, Języki, Hide-Login
Wzorce błędów wykraczające poza klasyczne pętle
Nie każde 301/302 jest prawdziwą pętlą - ale Błędne przekierowanie kosztów. Przekierowanie 301 na 404 sygnalizuje wyszukiwarkom "ten zasób jest tutaj na zawsze", ale zapewnia pustkę. Albo 302 zamiast 301 zapobiega trwałej konsolidacji sygnałów. Utrzymuję łańcuch na maksymalnie jednym lub dwóch poziomach, ustawiam 301 na stałe, 302 na tymczasowe przypadki i unikam utraty ciągów zapytań poprzez prawidłowe przekazywanie flag lub argumentów QSA.
Stabilne wdrożenia i dokumentacja
Aby zapobiec powstawaniu pętli w pierwszej kolejności, dokumentuję każda regułaKto kieruje co gdzie - i dlaczego? Używam środowiska przejściowego, odtwarzam tam zmiany reguł, rejestruję nagłówki i czasy, a następnie rozpowszechniam identyczne ustawienia serwera i wtyczek w produkcji. Krótka kontrola po wdrożeniu (strona startowa, logowanie, kasa, język) zapobiega awariom.
Podsumowanie w skrócie
Wydaję Pętla przekierowania Systematyczność: Sprawdź pliki cookie, zresetuj .htaccess do domyślnego, dostosuj adresy URL WP, ustaw poprawnie SSL, odizoluj wtyczki / motywy i poprawnie dostarczaj nagłówki serwera. Te kroki zwykle kończą pętlę w krótkim czasie. Następnie zabezpieczam instalację, dokumentuję przekierowania i aktualizuję aktualizacje. Dzięki temu logowanie jest dostępne, odwiedzający trafiają na właściwe strony, a wyszukiwarki indeksują się bez straty czasu. Ustrukturyzowane podejście pozwala uniknąć powtórzeń i oszczędza nerwy.
