Login-loop og „Cookies are blocked“ – kom ind i wp-admin igen

Kort svar: Når login-siden sender dig i ring eller klager over blokerede cookies, er det næsten altid én af tre ting: login-cookien bliver ikke sat eller ikke sendt med tilbage, login-siden bliver leveret fra cache, eller WordPress’ site-URL passer ikke til den adresse, du logger ind på. Test i inkognito først, ryd derefter cache af login-sider, og tjek til sidst site-URL, HTTPS og cookie-domæne for http/https- og www-mismatch.

Fagligt gennemgået: 2. oktober 2026

Du taster korrekt brugernavn og adgangskode, rammer Enter – og står på login-siden igen. Ingen fejlbesked, eller måske beskeden „Cookies are blocked or not supported by your browser“. De to symptomer hører til samme familie: login lykkes teknisk set, men sessionen overlever ikke turen tilbage til wp-admin.

Guiden går fra det hurtigste og mest sandsynlige til det mere tekniske: din egen browser, cache, site-URL, HTTPS bag en proxy, sikkerhedsplugins og til sidst sessioner og object cache. De fleste sager lukkes i de første to trin.

Før du ændrer noget: Tag en backup af databasen og en kopi af wp-config.php og .htaccess, før du retter site-URL eller cookie-indstillinger. En forkert site-URL kan låse alle brugere ude og sende sitet i en omdirigeringsløkke, så skriv de oprindelige værdier ned, inden du ændrer dem.

Sådan virker WordPress-login

Når du logger ind, sætter WordPress flere cookies: en login-cookie (wordpress_logged_in_…), der gælder hele sitet, og en godkendelsescookie, der kun sendes til /wp-admin/. Endelsen på cookienavnet er en hash af sitets URL. Samtidig gemmes et sessionstoken hos brugeren i databasen. Først når browseren sender cookien tilbage, og tokenet matcher, er du logget ind.

Beskeden om blokerede cookies kommer fra en testcookie, wordpress_test_cookie, som login-siden sætter, før du logger ind. Kan WordPress ikke læse den igen ved login, viser den advarslen. Det sker, når browseren afviser cookien, når login-siden kommer fra cache, eller når cookien sættes for et andet domæne eller en anden sti, end du står på.

Symptom	Sandsynlig årsag	Start her
Virker i inkognito, ikke i normal browser	Gamle cookies eller en browserudvidelse	Trin 1
Rammer alle brugere, cache-rydning hjælper kort	Login-siden eller wp-admin bliver cachet	Trin 2
Startede efter SSL-skift eller flytning	Site-URL med http eller forkert www-variant	Trin 3
Sitet ligger bag Cloudflare eller en proxy	WordPress tror, requesten er http	Trin 4
Startede efter installation eller fjernelse af sikkerhedsplugin	Login-regler eller rester i .htaccess	Trin 5
Kun én bruger rammes, på alle enheder	Ødelagte sessioner hos netop den bruger	Trin 6

1. Udeluk din egen browser

Åbn et inkognitovindue, og prøv at logge ind. Virker det dér, ligger problemet i din normale browserprofil: gamle cookies fra sitet, en udvidelse der blokerer cookies, eller strenge tracking-indstillinger. Slet alle cookies for dit domæne (ikke nødvendigvis alle cookies i browseren), og prøv igen. Virker det heller ikke i inkognito, er problemet på serversiden – gå videre til trin 2.

Tjek også computerens ur. Login-cookies har en udløbstid, og står klokken på din computer langt forkert, kan browseren betragte en helt ny cookie som udløbet. Det er sjældent, men det forklarer de sager, hvor kun én bestemt maskine aldrig kommer ind.

2. Er login-siden cachet?

En page cache må aldrig cache wp-login.php eller noget under /wp-admin/. Sker det alligevel, får du serveret en gammel udgave af login-siden med et udløbet sikkerhedstoken – og login fejler i ring. Det opstår typisk efter skift af cache-plugin, ved for aggressive cache-regler på CDN-niveau eller ved „cache alt“-regler i Cloudflare.

Du kan se det i svarets headere. Kør kommandoen to gange efter hinanden; et cache-hit på login-siden er altid en fejlkonfiguration:

curl -sI https://eksempel.dk/wp-login.php | grep -i -E "cache|age|x-litespeed|cf-cache"

• Ryd hele sitets cache – både i cache-pluginnet og i et eventuelt CDN.
• Tjek cache-headerne på login-siden: X-LiteSpeed-Cache: hit eller CF-Cache-Status: HIT på wp-login.php må ikke forekomme. Guiden CF-Cache-Status forklaret viser, hvordan headerne læses.
• Bruger du Cloudflare med egne cache-regler, så sørg for bypass på wp-login.php og /wp-admin/ – se wp-admin bag Cloudflare.
• Har du flyttet login-adressen med et plugin, skal den nye adresse også undtages fra cache – cache-pluginnet kender kun standardadressen.

3. Site-URL og cookie-domæne

Login-cookien sættes for det domæne, WordPress mener, sitet bor på. Logger du ind på https://www.ditdomæne.dk, mens site-URL’en står som http://ditdomæne.dk, passer cookien aldrig – og du ryger i loop. Det klassiske tidspunkt er lige efter et SSL-skift eller en flytning.

Tjek de to værdier under Indstillinger → Generelt eller med WP-CLI. De skal begge bruge https og præcis den variant – med eller uden www – som sitet reelt kører på:

wp option get siteurl
wp option get home
wp config get WP_HOME
wp config get WP_SITEURL

Er felterne i Indstillinger grå og kan ikke redigeres, er værdierne låst med WP_HOME og WP_SITEURL i wp-config.php; så er det dér, de skal rettes. Ret dem ét sted, og kontrollér, at redirects følger med. Guiderne www eller uden www og ERR_TOO_MANY_REDIRECTS dækker fælderne.

Kig også efter COOKIE_DOMAIN, COOKIEPATH og ADMIN_COOKIE_PATH i wp-config.php. De skal normalt slet ikke være defineret på et almindeligt site. En linje, der er kopieret med fra et gammelt domæne eller en multisite-opsætning, får cookien sat for det forkerte domæne – og så hjælper ingen cache-rydning. Fjern linjen, medmindre du ved præcis, hvorfor den står der.

Husk, at en ændret site-URL også ændrer cookienavnene. Alle brugere bliver derfor logget ud én gang, når du retter værdien. Det er forventet og ikke et nyt problem.

4. HTTPS bag Cloudflare eller en proxy

Ligger sitet bag Cloudflare, en load balancer eller en anden proxy, kan WordPress tro, at requesten kommer ind som http, selvom besøgende bruger https. Så sættes sikre cookies ikke korrekt, og FORCE_SSL_ADMIN sender dig i ring mellem http og https. Den klassiske årsag er Cloudflares SSL-tilstand „Flexible“, hvor forbindelsen fra Cloudflare til serveren er ukrypteret.

Den rigtige løsning er at bruge „Full (strict)“ med et gyldigt certifikat på serveren – se SSL-tilstande i Cloudflare. Ligger sitet bag en proxy, der sender headeren X-Forwarded-Proto, kan du lade WordPress respektere den ved at sætte dette øverst i wp-config.php:

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

Brug kun koden, når serveren faktisk står bag en proxy, du stoler på. På en almindelig server uden proxy er den unødvendig.

5. Sikkerhedsplugins og rester

Plugins, der flytter login-URL’en, begrænser login-forsøg, kræver totrinslogin eller binder sessioner til IP-adresser, kan skabe loops – især som efterladte rester: pluginnet er slettet, men dets regler står stadig i .htaccess eller i databasen. Ser du henvisninger til et gammelt sikkerhedsplugin i .htaccess, så fjern hele dets sektion – fremgangsmåden står i guiden om at gendanne .htaccess.

Sessioner bundet til IP-adresse er en særlig fælde på mobilnet og bag virksomheds-VPN, hvor IP-adressen kan skifte undervejs. Brugeren logger ind, IP’en skifter, og sessionen bliver afvist. Kan du ikke undvære funktionen, så slå IP-bindingen fra for administratorer, eller brug totrinslogin i stedet.

6. Ryd sessioner og object cache

Rammer problemet kun én bestemt bruger – på alle enheder og i inkognito – kan brugerens gemte sessioner være ødelagte, typisk efter en flytning eller en databasegendannelse. Med WP-CLI kan du fjerne alle sessioner for brugeren, så næste login starter forfra:

wp user session list admin
wp user session destroy admin --all
wp cache flush

wp cache flush tømmer en eventuel persistent object cache som Redis. Efter en flytning kan den indeholde gamle brugerdata og indstillinger, som får WordPress til at opføre sig, som om ændringerne i databasen ikke er sket.

Nødudgangen

Skal du ind nu, uanset årsag, så brug de manuelle veje: deaktiver mistænkte plugins ved at omdøbe deres mapper via SFTP, eller nulstil adgangen direkte. Begge fremgangsmåder er beskrevet trin for trin i låst ude af wp-admin og nulstil WordPress-adgangskode.

Verifikation

Problemet er løst, når login virker i både normal browser og inkognito, når wp-login.php svarer uden cache-hit i headerne, og når du kan logge ind og ud tre gange i træk uden loop. Test både med og uden www og med http i adresselinjen – alle varianter skal ende samme sted, og login skal holde.

Rammer det flere brugere samtidig, og hjælper cache-rydning kun midlertidigt, så er det cache-reglerne og ikke browserne, der skal rettes. Kommer du ikke i mål, kan Hostious’ danske support hjælpe med at gennemgå serverloggen og finde ud af, hvor sessionen knækker.

Læs også

• Hub: WordPress fejl og fejlfinding
• Låst ude af wp-admin
• Nulstil WordPress-adgangskode
• ERR_TOO_MANY_REDIRECTS i WordPress
• SSL-tilstande i Cloudflare: Flexible, Full og Full (strict)
• WordPress login: adresserne til login-siden
• WordPress hosting hos Hostious – LiteSpeed, daglig backup og dansk support 24/7

Ofte stillede spørgsmål om login-loop

Hvorfor rammer det kun mig og ikke min kollega?

Så ligger årsagen næsten sikkert i din browser: gamle cookies, en udvidelse eller en cachet udgave af login-siden hos dig. Inkognitotesten afgør det på 30 sekunder.

Kan et SSL-skift udløse login-loop?

Ja – hvis site-URL’en stadig står på http, mens sitet kører https, passer login-cookien ikke længere. Ret WP_HOME og WP_SITEURL til https-varianten, og ryd cachen bagefter.

Hjælper det at slette alle cookies?

Kun hvis problemet er lokalt hos dig. Slet cookies for dit eget domæne først – det rammer ikke dine logins andre steder. Fejler login stadig i inkognito, er cookies ikke problemet.

Hvad betyder „Cookies are blocked or not supported by your browser“?

At WordPress ikke kunne læse den testcookie, login-siden satte. Det skyldes oftest en cachet login-side, en forkert site-URL eller et forkert cookie-domæne – sjældnere at browseren faktisk blokerer cookies.

Hvorfor bliver alle logget ud, når jeg retter site-URL’en?

Fordi navnet på login-cookien er afledt af sitets URL. Når URL’en ændres, passer de gamle cookies ikke længere, og alle skal logge ind én gang til. Det er forventet.