Hoppa till innehåll 
Jag förklarar kortfattat och tydligt hur du kan skapa en Omdirigeringsslinga WordPress och på ett tillförlitligt sätt analysera och lösa dem. Jag kommer att visa dig omedelbart realiserbara lösningar för SSL-konflikter, felaktiga .htaccess-regler, felaktiga webbadresser, caching / cookies, plugin-problem och serverinställningar - inklusive tester och förebyggande åtgärder.
Centrala punkter
I följande lista sammanfattas de viktigaste stegen innan jag förklarar dem i detalj.
- Orsak snabbt begränsa: SSL, .htaccess, webbadresser, plugins, cache
- Standard-Kontrollera regler: .htaccess och wp-config.php
- HTTPS korrekt inställd: Certifikat, blandat innehåll, HSTS
- Insticksprogram Stäng av på testbasis: via instrumentpanel eller FTP
- Förebyggande åtgärder etablera: Säkerhetskopiering, dokumentation, övervakning
Vad innebär egentligen en redirect loop?
En Vidarebefordringsloop inträffar när URL A hoppar till URL B och B hoppar tillbaka till A - eller när flera hopp leder tillbaka till startadressen i slutet. Webbläsaren avbryter då med ERR_TOO_MANY_REDIRECTS och blockerar anropet. Jag känner ofta igen loopen genom att inloggningen laddar inloggningsformuläret igen efter korrekt inmatning. För besökarna ser det ut som en oändlig runda, för sökmotorerna som ett tekniskt fel. Detta kostar förtroende, förhindrar inloggningar till backend och äter upp värdefulla crawlbudgetar.
Huvudorsaker till loopar i WordPress
Jag hittar de vanligaste utlösarna i falska WordPress-URL:er, aggressiva .htaccess-regler, dubbla SSL-krav eller kaotiska plugin-omdirigeringar. Gamla cookies och hårda webbläsarcacher skickar också förfrågningar på villovägar. Efter domänändringar eller HTTPS-konverteringar uppstår fel oftare eftersom http och https blandas. I teman med egna omdirigeringar eller säkerhetsplugins kan reglerna blockera varandra. I sällsynta fall ställer skadlig kod avsiktligt in omdirigeringar för att låsa ut administratörer.
Snabbtester i webbläsaren: Cookies och cache
Jag börjar med en Klient-kontroll, eftersom det ger klarhet på några minuter. Jag raderar cookies och hela cacheminnet för den berörda domänen. Ett privat fönster hjälper till att utesluta gamla sessioner. Om inloggningen sedan fungerar berodde det på lokala data och inte på servern. Om felet fortsätter att uppstå går jag till server- och WordPress-nivå.
Kontrollera .htaccess och återställ till standard
Jag säkrar .htaccess och återställer dem till WordPress-standarden som ett test. På så sätt tar jag bort motstridiga omdirigeringar från tidigare experiment eller SEO-regler.
# BEGIN WordPress
RewriteEngine På
Omskrivningsbas /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
Omskrivningsvillkor %{REQUEST_FILENAME} !-d
Omskrivningsregel . /index.php [L]
# SLUT WordPress
När allt är igång kommer jag att lägga till ytterligare omdirigeringar steg för steg. För rena förhållanden hänvisar jag till htaccess-omdirigeringar med praktiska exempel. Viktigt: Tvinga aldrig fram http→https två gånger - det räcker med en gång på servernivå.
Anpassa WordPress-webbadresser i inställningar och wp-config.php
Avvikelser mellan WP_HOME och WP_SITEURL utlöser ofta ändlösa loopar, särskilt efter domänöverföringar. Jag kontrollerar först Inställningar > Allmänt. Om backend inte är tillgänglig ställer jag kort in värdena i wp-config.php:
define( 'WP_HOME', 'https://deinedomain.de' );
define( 'WP_SITEURL', 'https://deinedomain.de' );
I händelse av SSL-problem hos administratören avblockerar jag också tillfälligt åtkomsten:
define('FORCE_SSL_ADMIN', false);
Så snart jag är inne i instrumentpanelen ställer jag in korrekta webbadresser och tar bort konstanterna igen. Standardiserade adresser förhindrar upprepade loopar.
Rena lösningar på HTTPS/SSL-konflikter
Konflikter uppstår när SSL verkställs på serversidan och ett plugin ställer också in omdirigeringar. Jag testar först om certifikatet är giltigt och om HSTS eller proxyheaders stör igenkänningen. Sedan ser jag till att det finns en tydlig plats som verkställer https - helst på servernivå. Jag eliminerar konsekvent fel med blandat innehåll och felaktiga vidarebefordringskedjor. För den faktiska övergången hjälper dessa instruktioner mig att HTTPS-konvertering i WordPress.
Begränsning av plugins och teman som felkälla
Jag slår på misstänksam Insticksprogram särskilt omdirigerings-, SEO- och säkerhetsverktyg. Om jag inte kan komma in i backend, byter jag namn på wp-content/plugins-mappen till plugins.old via FTP. Sedan aktiverar jag varje plugin individuellt i instrumentpanelen tills felet dyker upp igen. Om du byter till ett standardtema som Twenty Twenty-Four visas också om temat bidrar med regler. Detta gör att jag snabbt kan hitta orsaken och skapa en konfliktfri konfiguration.
Sluta med inloggningsloopar: Cookies, sessioner, säkerhet
Om inloggningen misslyckas trots korrekt Uppgifter hoppar tillbaka igen, kontrollerar jag cookiens domän, sökväg och https-flagga. Jag rensar cacher på alla nivåer: Webbläsare, WordPress-cache, objektcache, CDN. För säkerhetsplugins kontrollerar jag regler som omdirigerar administratörswebbadresser eller begränsar inloggningar. Jag ställer tillfälligt in tydliga standardvärden för diagnostik och bygger sedan upp säkerheten bit för bit. Mål: En stabil session utan dubbla omdirigeringar.
Ställ in omvänd proxy, CDN och serverhuvud korrekt
Bakom en Proxy applikationer lätt förväxla http och https om Forwarded- eller X-Forwarded-Proto-rubriken saknas eller anländer felaktigt. Jag kontrollerar Nginx/Apache-konfigurationer, inställningar för lastbalanserare och CDN-vidarebefordran. Det är viktigt att WordPress känner igen den faktiska klient-URL:en korrekt. För konfigurationer med en uppströms proxy hjälper den här guiden mig att Konfigurera omvänd proxy. Detta förhindrar motstridiga regler mellan server, CDN och plugin.
Malware som den sista källan till misstankar
Om slingan fortfarande kan slutas trots alla korrigeringar inte Jag skannar installationen efter skadlig kod. Jag jämför kärnfiler med original, kontrollerar nyare administratörer och cron-jobb. Jag avslöjar omdirigeringar i rubriker, mallfiler eller via JavaScript genom att söka efter window.location, meta refresh eller obskyra Base64-strängar. Efter upprensningen återställer jag lösenord och gör en ny säkerhetskopia. Säkerhet mot återinfektion sparar mycket tid senare.
Profylax och övervakning i vardagen
Jag förhindrar loopar genom att Förändringar centralt hantera omdirigeringar och testa dem i en staging-miljö före live-distributioner. Jag skapar säkerhetskopior automatiskt och håller plugins och teman uppdaterade. Efter domänändringar kontrollerar jag webbplatsens webbadresser, SSL och omdirigeringskedjor. Ett litet övervakningssystem meddelar mig om statuskodshopp i ett tidigt skede. Följande tabell hjälper till med snabb diagnostik under drift.
| Symptom | Möjlig orsak | Direkt åtgärd | Testverktyg |
|---|---|---|---|
| ERR_TOO_MANY_REDIRECTS | Dubbel https-övervakning | Använd endast en plats för omdirigeringar | Kontroll av HTTP-huvud, Curl |
| Inloggning hoppar tillbaka | Konflikt om cookie/session | Ta bort cookies, töm cacheminnet | Privat fönster, DevTools |
| Startsidan laddas inte | .htaccess-slinga | Aktivera standard .htaccess | Serverloggar, diff |
| Felaktig endast under fullmakt | Felaktig Proto-huvud | Ställ in X-Forwarded-Proto korrekt | Proxy-konfiguration, Header-spårning |
| Plötsligt från rankning | Omdirigera kedjor | Minska kedjor, 301 korrekt | Krypande, skrikande groda |
Spåra omdirigeringar exakt: Header trace och curl
Innan jag vänder mig till konfigurationer drar jag exakt kedja till. I DevTools (fliken Network) kan du se varje hopp med statuskod och platshuvud. På skalet är ofta tillräckligt:
curl -IL https://deinedomain.de
# eller detaljerad med visning av varje omdirigering
curl -IL --max-redirs 20 https://deinedomain.de
Jag håller utkik efter mönster som http→https→http (fram och tillbaka) eller www↔non-www. En 302 som följer på en 301 är också misstänkt. Om även den första begäran omdirigeras till /wp-login.php är orsaken vanligtvis i plugin/tema eller cookies; om det händer globalt är det ofta .htaccess eller server.
Riktad användning av server- och WordPress-loggar
Loggar sparar timmar. Jag aktiverar felsökningsloggen i wp-config.php utan att visa den för besökare:
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);
@ini_set('display_errors', 0);
Sedan kontrollerar jag /wp-content/debug.log för indikationer (t.ex. "Kan inte ändra rubrikinformation" före en omdirigering). Samtidigt kontrollerar jag webbserverns loggar. För Apache: access.log och error.log, för Nginx: access.log med status 301/302. En titt på användaragenten hjälper till att avgöra om det bara är bots eller alla användare som påverkas.
WP-CLI: snabb räddning via konsolen
Om instrumentpanelen inte är tillgänglig löser jag en hel del saker via WP-CLI:
# Kontrollera och ange webbadresser
wp-alternativ få hem
wp alternativ få siteurl
wp-alternativ uppdatera hem 'https://deinedomain.de'
wp-alternativ uppdatera siteurl 'https://deinedomain.de'
# "Spara genom" permalänkar en gång
wp omskrivning flush --hård
# Töm cacher
wp rensa cache
wp tillfällig radering --all
# Avaktivera / testa plugins en massa
wp plugin avaktivera --all
wp plugin aktivera klassisk redaktör
På så sätt kan jag återvända till systemet utan risk, hitta de skyldiga och bara aktivera det som verkligen behövs.
www, slash och kanonisering utan loop
Slingor skapas ofta av små inkonsekvenserwww vs. icke-www, saknad/tilläggsslash eller blandad proto. Jag bestämmer mig för en variant och sätter bara en Regelkedja. Exempel på icke-www→www i Apache (utan dubbel https-tillämpning):
Omskrivningsmotor på
# Vidarebefordra endast om värden inte redan är www
RewriteCond %{HTTP_HOST} !^www\. [NC]
RewriteRule ^(.*)$ https://www.%{HTTP_HOST}/$1 [L,R=301]
Med Nginx ställer jag in en tydlig server block forwarding och undviker blandade regler i PHP/plugins. Viktigt: Först kanonisering (www/slash), sedan https - och endast till en Position.
Clean bakom proxy/CDN: Känna igen HTTPS korrekt
Om WordPress ligger bakom en lastbalanserare eller CDN, tar backend ofta bara emot http, även om klienten använder https. WordPress känner då igen is_ssl() felaktigt och genererar loopar. Jag korrigerar servervariablerna tidigt i wp-config.php:
if (isset($_SERVER['HTTP_X_FORWARDED_PROTO']) && $_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https') {
$_SERVER['HTTPS'] = 'on';
}
Jag ställer också in rubrikerna X-Forwarded-Proto och Forwarded clean på proxyn. Jag använder HSTS sparsamt: Om HSTS är aktivt kan det ingen http-sökväg, annars hänger sig webbläsaren. Jag använder bara preload när alla subdomäner kör stabilt på https.
Desarmera inloggnings- och cookiefällor
En vanlig källa är felaktigt inställda cookies. Jag brukar ställa in ingen COOKIE_DOMAIN. Om det har definierats en gång ändrar jag det som ett test:
define('COOKIE_DOMAIN', false);
Jag kontrollerar också om admin-cookieflaggan "Secure" är inställd under https och om sökvägen är inställd på "/". Vid ihållande problem tar jag bort sessioner på serversidan (t.ex. startar om php-fpm) och tömmer objektcachen/redis så att gamla nonces inte längre får effekt.
Specialfunktioner för multisite- och domänmappning
På Flera webbplatser-inställningar leder olika mappningar snabbt till en loop: Subdomän- eller katalogläge, olika protokoll eller en gammal plugin för domänmappning med egna omdirigeringar. Jag kontrollerar blogg- och webbplatstabellerna, synkroniserar protokoll och värdar och avaktiverar kort auto-redirects för språkbyte. En "Super Admin"-inloggning i huvudbloggen hjälper till att se nätverksomdirigeringar centralt. Viktigt: Endast en instans beslutar om den kanoniska domänen.
WooCommerce, flerspråkighet och "Dölj inloggning"
Butiker och flerspråkiga webbplatser har ytterligare omdirigeringslogik: tvingade SSL-sidor (kassa / konto), språkomdirigering till Accept-Language eller "Hide Login" -funktioner i säkerhetsplugins. För diagnosen avaktiverar jag den automatiska språkomdirigeringen och tillåter tillfälligt /wp-login.php utan avledning. I WooCommerce ställer jag in "Endast dessa sidor på SSL" antingen rent på serversidan eller helt systemomfattande så att inga blandade tillstånd uppstår.
Koordinera objektcache, opcode- och edge-cache
Flera cachningslager kan varandra amplify: PHP opcode (OPcache), objektcache (Redis/Memcached), sidcache för plugins och CDN edge. Jag tömmer dem i en ordnad sekvens så att inget lager returnerar gamla omdirigeringar. Efter regeländringar ogiltigförklarar jag edge-cachen helt och hållet. Först då är ett test meningsfullt.
Typiska Nginx-fällor
Med Nginx uppstår loopar när platsblock skrivs om två gånger eller /index.php lever internt och externt. Jag använder en enda ren konfiguration: först serverblockets vidarebefordran (www/https), sedan en tydlig try_files på /index.php. Jag undviker konsekvent blandningar av add_header refresh och 301/302.
Checklista: hitta orsaken på 10 minuter
- Ta bort cookies/cache lokalt, testa i inkognitoläge
- kör curl -IL och se kedjan
- Återställ .htaccess/Nginx till standardsökväg
- Synkronisera WP_HOME/WP_SITEURL (om nödvändigt via WP-CLI)
- Endast en instans tillämpar https (server föredras)
- Avaktivera plugins/tema, aktivera steg för steg
- Ställ in proxyhuvudet korrekt, kontrollera is_ssl()
- Tomt objekt/sida/kant-cache
- Kontrollera loggar: debug.log, access/error.log
- Särskilda funktioner: Multisite, Woo, Språk, Hide-Login
Felmönster utöver klassiska slingor
Inte varje 301/302 är en riktig loop - men Felaktig rutt kostnader också. En 301 till 404 signalerar till sökmotorer "den här resursen är här för alltid", men ger tomhet. Eller en 302 i stället för 301 förhindrar en permanent konsolidering av signaler. Jag håller kedjan till högst en eller två nivåer, sätter 301 för permanenta, 302 för tillfälliga fall och undviker förlust av frågesträngar genom att skicka QSA-flaggor eller args på rätt sätt.
Stabila driftsättningar och dokumentation
För att förhindra att slingor uppstår i första hand dokumenterar jag varje regelVem dirigerar vad till var - och varför? Jag använder en staging-miljö, spelar igenom regeländringar där, loggar rubriker och tider och distribuerar sedan identiska server- och plugin-inställningar i produktionen. En kort kontroll efter distributionen (startsida, inloggning, utcheckning, språk) förhindrar misslyckanden.
Slutsats i korthet
Jag släpper en Vidarebefordringsloop Systematiskt: Kontrollera cookies, återställ .htaccess till standard, anpassa WP-URL:er, ställ in SSL korrekt, isolera plugins/tema och leverera serverheaders korrekt. Dessa steg avslutar vanligtvis loopen på kort tid. Jag säkrar sedan installationen, dokumenterar omdirigeringar och håller uppdateringar uppdaterade. På så sätt förblir inloggningen tillgänglig, besökarna landar på rätt sidor och sökmotorerna crawlar utan att förlora tid. Ett strukturerat arbetssätt undviker upprepningar - och sparar nerver.
