ERR_TOO_MANY_REDIRECTS i WordPress — sådan bryder du sløjfen

Kort svar: For mange omdirigeringer (ERR_TOO_MANY_REDIRECTS) betyder, at to regler sender browseren frem og tilbage mellem to adresser – næsten altid uenighed om www eller HTTPS. Følg kæden med curl eller browserens netværksfane, så du ser, hvilke to adresser der skiftes mellem. Ret derefter den regel, der er i overskud: WordPress-adresserne, en .htaccess-regel, et plugin eller Cloudflares SSL-tilstand.

Fagligt gennemgået: 2. oktober 2026

ERR_TOO_MANY_REDIRECTS betyder, at browseren blev sendt frem og tilbage mellem adresser, indtil den gav op. I WordPress skyldes det næsten altid, at site-adressen og den adresse, serveren eller en proxy tvinger, ikke er enige – typisk om www eller om HTTPS.

Fejlen hedder det samme i Chrome og Edge. Firefox kalder den “Siden viderestiller ikke korrekt”, og Safari skriver, at der er for mange omdirigeringer. Det er den samme sløjfe. Filerne og databasen er uberørte; det er kun vejvisningen, der er i stykker.

Før du ændrer noget: Tag en backup af .htaccess, wp-config.php og databasen, og notér de nuværende værdier for WordPress-adresse og webstedsadresse. Ret én regel ad gangen, og test i et privat vindue efter hver ændring – ellers ved du ikke, hvilken ændring der løste (eller flyttede) problemet.

Hvad der sker i en omdirigeringssløjfe

Serveren siger til browseren: gå til adresse B. Adresse B siger: gå til adresse A. Browseren følger med op til omkring 20 gange og stopper så. Der findes ingen side at vise, fordi de to regler modsiger hinanden.

Det klassiske eksempel: WordPress er sat op med https://dinside.dk, mens serveren omdirigerer alt til https://www.dinside.dk. Så sender WordPress tilbage uden www, og serveren sender frem igen.

En lidt sværere variant opstår bag en proxy som Cloudflare eller en load balancer. Besøgende taler HTTPS med proxyen, men proxyen taler HTTP med serveren. WordPress ser derfor en HTTP-forespørgsel, sender en omdirigering til HTTPS, og proxyen henter igen over HTTP. Sløjfen lever, selv om alle adresser i WordPress er rigtige.

Symptom og sandsynlig årsag

Symptom	Sandsynlig årsag	Første kontrol
Sløjfe mellem www og uden www	WordPress-adresse og serverens www-regel er uenige	Indstillinger → Generelt og .htaccess
Sløjfe mellem http og https	Dobbelt HTTPS-tvang eller proxy, der taler HTTP med serveren	Cloudflares SSL-tilstand og SSL-plugins
Kun wp-admin fejler	WP_SITEURL eller en regel, der rammer /wp-admin/	wp-config.php og sikkerhedsplugin
Fejlen kom lige efter en flytning	Gamle regler fra tidligere udbyder	.htaccess og eventuelle serverregler
Kun én bruger eller én browser fejler	Gammel cookie eller cachet 301-omdirigering	Privat vindue og ryd cookies
Kun én side eller ét sprog fejler	Omdirigeringsplugin eller sprogplugin	Pluginets omdirigeringsliste

1. Se selve kæden, før du gætter

Det vigtigste fejlfindingsskridt er at se, hvilke adresser der skiftes mellem. Fra en terminal viser curl hver omdirigering med statuskode og Location-header:

curl -sIL --max-redirs 10 https://dinside.dk/ | grep -iE "^(HTTP|location|server|cf-ray)"

Læs svaret som en kæde. Står der skiftevis https://www.dinside.dk/ og https://dinside.dk/, er det en www-konflikt. Skifter den mellem http:// og https://, er det HTTPS-tvang eller en proxy. Optræder cf-ray, går trafikken gennem Cloudflare.

Uden terminal kan du bruge browserens udviklerværktøjer: åbn fanen Netværk, slå “Bevar log” (Preserve log) til, og indlæs siden. Hver række med 301 eller 302 viser i headerne, hvor den sender dig hen. Headeren X-Redirect-By: WordPress fortæller, at det er WordPress selv – eller et plugin via WordPress – der omdirigerer, og ikke serveren.

2. Ryd cookies og test i et privat vindue

En gammel cookie kan holde sløjfen i live, selv efter fejlen er rettet. Browsere husker også permanente 301-omdirigeringer aggressivt. Test derfor altid i et privat vindue, mens du fejlfinder, og ryd cookies for domænet, når du tester i dit normale vindue.

Rammer fejlen kun dig, men ikke kolleger eller curl, er det næsten altid lokal cache eller cookies – ikke sitet.

3. Gør WordPress-adresserne ens

Under Indstillinger → Generelt skal WordPress-adresse og Webstedsadresse normalt være identiske og matche den adresse, serveren tvinger. Er du låst ude af wp-admin, kan du sætte dem direkte i wp-config.php. Vælg én skrivemåde – med eller uden www – og brug den begge steder:

define( 'WP_HOME', 'https://dinside.dk' );
define( 'WP_SITEURL', 'https://dinside.dk' );

Placér linjerne over kommentaren “That’s all, stop editing!”. De overstyrer databasen, så du kan komme ind igen. Fjern dem bagefter, hvis du hellere vil styre adresserne fra Indstillinger → Generelt – så længe de står i filen, er felterne i administrationen låst.

Har du WP-CLI, kan du læse og rette værdierne direkte:

wp option get home
wp option get siteurl
wp option update home 'https://dinside.dk'
wp option update siteurl 'https://dinside.dk'

4. Kig i .htaccess

Omdøb .htaccess til .htaccess_gammel og prøv igen. Virker forsiden, lå fejlen dér. Gå derefter ind under Indstillinger → Permalinks og tryk Gem, så WordPress skriver en ny, ren fil. Se også guiden til at gendanne WordPress’ standard-.htaccess.

Har du selv tilføjet en www- eller HTTPS-regel, skal den kun stå ét sted. To regler, der begge vil bestemme, er den hyppigste kilde til sløjfen. En samlet regel, der sender alt til https:// uden www i ét hop, ser sådan ud på Apache og LiteSpeed:

RewriteEngine On
RewriteCond %{HTTPS} off [OR]
RewriteCond %{HTTP_HOST} ^www\. [NC]
RewriteRule ^ https://dinside.dk%{REQUEST_URI} [L,R=301]

Står sitet bag en proxy, der taler HTTP med serveren, vil %{HTTPS} off altid være sand, og reglen skaber selv en sløjfe. Så skal reglen enten fjernes og HTTPS-tvangen overlades til proxyen, eller betingelsen skal tjekke X-Forwarded-Proto i stedet.

5. Tjek Cloudflare og andre proxyer

Bruger du Cloudflare, skal SSL/TLS-tilstanden stå på Full eller Full (strict) – aldrig Flexible, når serveren selv har et gyldigt certifikat og tvinger HTTPS. Flexible er den enkeltindstilling, der skaber flest omdirigeringssløjfer, fordi Cloudflare så taler HTTP med serveren. Læs mere om forskellen på Flexible, Full og Full (strict) og om redirect-sløjfer mellem Cloudflare og WordPress.

Kan proxyen ikke tale HTTPS med serveren, skal WordPress have at vide, at den oprindelige forespørgsel var sikker. Det gøres i wp-config.php over “stop editing”-linjen:

if ( isset( $_SERVER['HTTP_X_FORWARDED_PROTO'] ) && $_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https' ) {
    $_SERVER['HTTPS'] = 'on';
}

Brug kun denne løsning, når du ved, at forespørgslerne faktisk kommer gennem en proxy, du styrer. Full (strict) med et gyldigt certifikat på serveren er den renere løsning.

6. Find pluginet, der omdirigerer

SSL-plugins, sikkerhedsplugins, omdirigeringsplugins og sprogplugins tilføjer deres egne omdirigeringer, og to af dem sammen giver næsten altid en sløjfe. Viser kæden X-Redirect-By med et pluginnavn, har du svaret med det samme.

Ellers deaktiverer du på staging plugins ét ad gangen. Er du låst ude, kan du omdøbe den enkelte pluginmappe under wp-content/plugins/ via SFTP, eller bruge WP-CLI:

wp plugin list --status=active
wp plugin deactivate navn-paa-ssl-plugin

Husk også cachen: et cacheplugin eller en CDN kan have gemt selve omdirigeringen. Ryd cachen efter hver rettelse, ellers tester du den gamle sløjfe igen. Se sådan finder du en plugin- eller temakonflikt uden at ramme live-sitet.

Hvis det stadig sker

Er du netop flyttet, kan der ligge regler tilbage fra den gamle udbyder – i .htaccess, i en serverkonfiguration eller i databasen, hvis en søg-og-erstat ikke fik alle adresser med. Søg efter den gamle adresse med wp search-replace 'http://gammel' 'https://ny' --dry-run, før du ændrer noget. Flytter du til Hostious med gratis migrering, så bed supporten tjekke omdirigeringerne som en del af flytningen.

Har sitet tidligere sendt HSTS-headeren, husker browseren, at domænet kun må hentes over HTTPS. Det skaber ikke sløjfen i sig selv, men det betyder, at du ikke kan “løse” en sløjfe ved at gå tilbage til HTTP. Ret i stedet konflikten, så HTTPS virker hele vejen.

Verificér, at sløjfen er brudt

• Kør curl -sIL mod alle fire varianter: http og https, med og uden www. Alle skal ende på den samme adresse med status 200 i højst ét eller to hop.
• Test forsiden, en underside og /wp-admin/ i et privat vindue.
• Log ind og ud, så du ved, at login-cookien sættes på den rigtige adresse.
• Ryd cache i plugin, server og CDN, og test igen.
• Fjern midlertidige linjer i wp-config.php, hvis du kun brugte dem til at komme ind.

Sådan undgår du den fremover

• Vælg én kanonisk adresse – med eller uden www – og hold fast i den overalt. Se www eller uden www.
• Lad kun ét sted styre HTTPS: enten serveren, proxyen eller et plugin – ikke flere.
• Brug Full (strict) i Cloudflare, når serveren har et gyldigt certifikat.
• Ryd op i .htaccess og omdirigeringsplugins efter enhver flytning.
• Test ændringer i omdirigeringer på staging først.

Læs også

• Hub: WordPress fejl og fejlfinding
• For mange redirects mellem Cloudflare og WordPress
• Mixed content efter SSL
• Låst ude af wp-admin
• WordPress hosting hos Hostious – LiteSpeed, gratis SSL og dansk support 24/7

Ofte stillede spørgsmål om for mange omdirigeringer

Er min hjemmeside gået ned?

Nej. Filerne og databasen er uberørte. Det er kun vejvisningen mellem to adresser, der er i sløjfe, og den kan rettes uden at gendanne noget.

Skal jeg bruge www eller ej?

Det betyder ikke noget for placeringen – men vælg én og omdiriger den anden til den i ét hop. Det vigtige er, at WordPress, serveren og eventuel Cloudflare er enige om valget.

Hvorfor kan jeg se siden, men ikke wp-admin?

Så gælder sløjfen kun for administrationen, og det peger på WP_SITEURL eller på en regel, der specifikt rammer /wp-admin/ – ofte fra et sikkerhedsplugin. Sammenlign WP_SITEURL med WP_HOME, og deaktivér sikkerhedspluginet midlertidigt.

Hvordan ser jeg, hvilke adresser der skiftes mellem?

Kør curl -sIL mod adressen, eller åbn Netværk-fanen i browserens udviklerværktøjer med “Bevar log” slået til. Location-headerne viser kæden, og X-Redirect-By afslører, om det er WordPress eller et plugin, der omdirigerer.