For mange redirects mellem Cloudflare og WordPress

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.

Bekræft loopets to ender

Å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:

• statuskode, typisk 301, 302, 307 eller 308;
• fuld Location-værdi;
• om protokollen skifter mellem HTTP og HTTPS;
• om værtsnavnet skifter mellem www og uden www;
• om en path eller trailing slash ændres frem og tilbage.

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

Løsning 1: ret Flexible-konflikten

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:

1. installér eller verificér et certifikat på origin;
2. kontrollér at webserveren svarer korrekt på HTTPS med det rigtige hostname;
3. skift Cloudflare til Full (strict), når certifikatet kan valideres;
4. behold én kontrolleret HTTP-til-HTTPS-regel.

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.

Løsning 2: saml www-normaliseringen ét sted

Væ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:

1. Cloudflare Single Redirects og eventuelle ældre Page Rules;
2. webserverens vhost, .htaccess eller Nginx-regler;
3. WordPress-adresse og webstedsadresse under Indstillinger → Generelt;
4. redirect-, SSL- og sikkerhedsplugins;
5. custom code eller hostens kontrolpanel.

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.

Løsning 3: få WordPress til at genkende HTTPS bag proxyen

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.

Løsning 4: gennemgå Cloudflare-regler og HSTS

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.

Løsning 5: gendan WordPress-adgang uden direkte databasegæt

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.

Fire redirectmønstre, du kan genkende i kæden

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.

Mikroeksempel: et loop med to ejere

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.

Sådan eftertester du

• HTTP til canonical HTTPS bruger højst det forventede ene redirect.
• Canonical HTTPS svarer 200 OK uden ekstra hop.
• Både apex og www ender på samme valgte hostname.
• /wp-admin/ og login virker i en ny browserprofil.
• En formular-POST eller checkout ændrer ikke protokol eller hostname.
• Canonical, og:url og WordPress-adresser bruger samme HTTPS-URL.
• Network-loggen viser ingen gentagende Location-par.

Rul tilbage

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.

Hvornår skal hosting eller udvikler hjælpe?

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.

Ofte stillede spørgsmål om redirect-loops

Hvorfor opstår ERR_TOO_MANY_REDIRECTS med Cloudflare?

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.

Hvordan ser jeg selve redirect-kæden?

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.

Hvad er den rigtige løsning på loopet?

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.

Læs også

• Cloudflare 525 og 526 hjælper, hvis Full (strict) blotlægger en TLS-fejl.
• Cloudflare-indstillinger til WordPress beskriver den stabile målopsætning.
• Cloudflare DNS: orange eller grå sky forklarer, hvilke hostnames der går gennem proxyen.
• Ved et langsomt svar uden loop: Cloudflare Error 524.
• Se alle emner i Cloudflare-guides til WordPress.
• WordPress hosting hos Hostious – hosting der er hurtig uden ekstra lag ovenpå

Sådan dokumenterer du dit eget redirect-loop

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.