Kort svar: En redirect-loop opstår, når to lag er uenige om protokol eller værtsnavn. Det klassiske tilfælde er Cloudflare Flexible, mens origin tvinger HTTP til HTTPS. Gem redirect-kæden først. Kontrollér derefter SSL/TLS-mode, WordPress-adresser, serverredirects og Cloudflare Redirect Rules. Ret kun det lag, der sender requesten tilbage. Ryd ikke hele siden eller databasen; målet er én kanonisk URL og højst ét nødvendigt redirect før
200 OK.
Risiko: Middel Forventet tid: 20-60 minutter Hav klar: Hostingadgang, WordPress-adgang, den fulde redirect-kæde og en kopi af nuværende regler
Fagligt gennemgået: 28. august 2026 Kontrolgrundlag: WordPress 7.1, PHP 8.4.23 og Chrome 151. Redirectlogikken er gennemgået fagligt; Hostious er ikke bag Cloudflare. En syntetisk stagingkæde kan vise, hvordan et loop ser ud, men må ikke forveksles med et observeret Cloudflare-loop på produktion.
Browserens ERR_TOO_MANY_REDIRECTS fortæller, at den samme request bliver sendt rundt uden at nå en endelig side. Cloudflare kan være det ene lag, mens WordPress, webserveren, et plugin, HSTS eller en anden Cloudflare-regel er det andet. Fejlen løses hurtigst ved at følge hvert Location-headerhop — ikke ved at slå funktioner fra i tilfældig rækkefølge.
På denne side
Åbn browserens Network-panel med “Preserve log”, eller hent kun headers med et værktøj, der kan vise redirect-kæden. Notér for hvert hop:
Location-værdi;www og uden www;Brug en test-URL uden personlige query-parametre. Et eksempel på en lokal kontrol er:
curl -I -L --max-redirs 10 "$DIN_TEST_URL"Kommandoen er et kontrolmønster, ikke et testbevis for din side.
| Redirectmønster | Mest sandsynlige konflikt | Første kontrol | Sikker retning |
|---|---|---|---|
| HTTPS → HTTP → HTTPS | SSL-mode og originredirect | Cloudflare SSL/TLS Overview | Brug HTTPS til origin og stop HTTP-returen |
www → apex → www | To kanoniske værtsnavne | Cloudflare-regel, server og WordPress URL | Vælg én ejer og ét mål |
/side ↔ /side/ | Rewrite- eller pluginregel | Serverregler og WordPress permalink | Fjern den modsatrettede regel |
| Kun wp-admin/login looper | WordPress ser requesten som HTTP | Reverse proxy-header og is_ssl() | Ret HTTPS-detektion på origin |
| Loop fortsætter efter regelændring | HSTS/browsercache eller andet lag | Ny privat profil og headerkontrol | Skeln browserpolitik fra serverredirect |
I Flexible-tilstand modtager browseren HTTPS fra Cloudflare, men Cloudflare kontakter origin over HTTP. Hvis origin tvinger alle HTTP-requests til HTTPS, sender den requesten tilbage til Cloudflare, som igen bruger HTTP til origin. Resultatet er en loop.
Den normale, sikre løsning er:
At fjerne HTTPS-redirecten på origin kan stoppe loopet i Flexible, men efterlader forbindelsen mellem Cloudflare og origin ukrypteret. Det bør ikke være sluttilstanden for en normal WordPress-side.
www-normaliseringen ét stedVælg om canonical skal være HTTPS-versionen med eller uden www. WordPress-adresse, webstedsadresse, canonical-tag og redirect skal pege samme vej.
Gennemgå i denne rækkefølge:
.htaccess eller Nginx-regler;Deaktivér eller ret den modsatrettede regel. Slet ikke alle redirects: en fungerende canonical-redirect er ønsket og bevarer både bruger- og søgemaskinesignaler.
WordPress bruger sin HTTPS-detektion til admincookies og redirects. Bag en reverse proxy kan origin modtage en intern forbindelse på en måde, der får WordPress til at tro, at requesten er HTTP, selv om besøgeren bruger HTTPS.
Kontrollér først, at proxyen sender en korrekt X-Forwarded-Proto-værdi, og at origin kun stoler på headeren fra kendte proxies. Hvis WordPress stadig fejldetekterer protokollen, kan en afgrænset wp-config.php-tilpasning være nødvendig. Brug WordPress' officielle reverse-proxy-mønster, tag filbackup, og placer ændringen før WordPress indlæses.
Indsæt ikke en ubetinget $_SERVER['HTTPS'] = 'on' på enhver request. Det kan maskere en forkert proxyopsætning og gøre lokale eller direkte requests sværere at diagnosticere.
Cloudflare kan have flere aktive redirectprodukter. En Single Redirect kan matche før en anden regel, mens en gammel Page Rule stadig ligger i kontoen. Brug Rule Trace, hvis det er tilgængeligt, eller deaktiver én mistænkt regel ad gangen i et kort testvindue.
Always Use HTTPS og en serverredirect til HTTPS er normalt ikke i sig selv en loop, hvis alle lag er enige. Problemet kommer, når et andet lag sender HTTPS tilbage til HTTP eller et andet hostname.
HSTS er en browserpolitik, som kan omskrive HTTP til HTTPS, før requesten rammer Cloudflare. Test derfor også i en ny browserprofil og med headers. Slå ikke HSTS til eller fra som første forsøg. Hvis includeSubDomains eller preload er aktiv, kan konsekvensen vare længere end dashboardændringen.
Hvis wp-admin ikke kan åbnes, brug først hostingens sikre WordPress-værktøj eller WP-CLI til at læse home og siteurl. Sammenlign dem med det valgte HTTPS-hostname. Ret kun den forkerte værdi og gem den gamle til rollback.
Direkte databasesøg-og-erstat er ikke nødvendig ved en simpel redirect-loop og kan ændre serialiserede værdier eller indhold unødigt. Hvis en migrering har efterladt mange gamle absolutte URL'er, er det en separat migreringsopgave med backup og fuld crawl bagefter.
HTTP og HTTPS skifter plads. Et hop går til HTTPS, næste tilbage til HTTP. Det klassiske ejerpar er edge-SSL og originens HTTPS-tvang. Kontrollér især Flexible. Når origin har et gyldigt certifikat, er målet normalt Full (strict), så både besøger→Cloudflare og Cloudflare→origin bruger HTTPS.
www og roddomæne skifter plads. Cloudflare-reglen sender mod www, mens WordPress eller webserveren sender tilbage. Vælg én kanonisk host og lad ét lag udføre normaliseringen. Andre lag må acceptere målhosten uden et modgående redirect.
Samme URL gentages med små queryændringer. Et login-, sprog-, samtykke- eller sikkerhedsplugin kan tilføje og fjerne parameteren. Gem hele kæden, men fjern tokens før deling. Test pluginets præcise betingelse på staging; en global deaktivering kan skjule årsagen og ændre brugerflowet.
Kun /wp-admin/, login eller checkout looper. Forsiden kan være korrekt, mens proxyheaders, sikre cookies eller applikationsregler er forskellige på den dynamiske path. Følg Location og Set-Cookie for den konkrete route. Del kun cookienavne — aldrig værdier.
Antag, at http://eksempel.dk først går til https://www.eksempel.dk ved edge-laget. Origin sender derefter til https://eksempel.dk, fordi WordPress-adressen er uden www. En anden edge-regel normaliserer igen til www. Den rigtige løsning er ikke flere undtagelser, men én besluttet kanonisk host og én ansvarlig redirect. Når den er valgt, skal alle fire startvarianter ende på samme URL uden at vende tilbage til en tidligere adresse.
Test kæden uden browsercache med en headerklient og igen i en frisk browser. Det første viser de rå hop; det andet afslører HSTS, cookies og applikationsflow. Forskellen mellem resultaterne er i sig selv et nyttigt signal.
200 OK uden ekstra hop.www ender på samme valgte hostname./wp-admin/ og login virker i en ny browserprofil.og:url og WordPress-adresser bruger samme HTTPS-URL.Location-par.Genaktivér den senest deaktiverede regel eller gendan den gamle WordPress-/serverværdi, hvis testen bliver værre. Hvis du ændrede wp-config.php, brug den gemte filbackup. Gendan ikke Flexible efter at Full (strict) er verificeret; ret i stedet den specifikke regel, der introducerede loopet.
Hosting skal hjælpe, når origin-certifikat, reverse proxy-header eller webserverregler er involveret. En udvikler er relevant ved plugin- eller kodegenererede redirects og migreringsdata. WordPress-hosting hos Hostious kan være relevant, hvis både proxy og WordPress skal gennemgås.
Typisk fordi Cloudflare står på Flexible SSL, mens serveren tvinger HTTPS: origin ser HTTP, redirecter til HTTPS, Cloudflare henter igen over HTTP – og løkken er sluttet.
Med curl -IL på URL’en eller browserens Netværk-fane: følg Location-headerne, og notér hvem der omdirigerer til hvad. Kæden viser præcis, hvilke to lag der er uenige.
Sæt Cloudflare til Full (strict) med gyldigt origin-certifikat, og lad ÉT lag eje HTTP→HTTPS-redirectet. Tjek også at WordPress- og Site-URL begge står med https.
Gem redirectkæden som en række statuskoder og Location-værdier, før du rydder cookies eller ændrer en regel. Den afgørende oplysning er ofte de to URL'er, som skifter frem og tilbage: HTTP mod HTTPS, www mod uden www eller en login-/sprogvariant. Maskér queryparametre, der indeholder tokens, men bevar protokol, hostname og path.
Skriv ud for hvert hop, hvilket lag der sandsynligvis ejer det: Cloudflare Redirect Rule, webserver, WordPress-adresser, plugin eller applikationskode. Gæt ikke ud fra navnet alene. Kontrollér reglen eller loggen, og ændr derefter kun én ejer. Et praktisk notat kan være: “Hop 1 fra edge, hop 2 fra origin; origin tvang HTTPS, mens edge talte HTTP til origin.”
Efter rettelsen skal den rene kæde gemmes igen. Kontroller både roddomæne, www, HTTP, HTTPS og den konkrete problem-URL; en forside kan være korrekt, mens login eller checkout stadig looper. Notér også rollback og om HSTS var aktiv. Når HSTS er sendt til browseren, kan den lokale test fortsætte med at tvinge HTTPS, selv efter at en regel er ændret, og derfor bør headerkontrollen supplere browserens visning.