WordPress login redirect loop: waarom dit gebeurt

Een login redirect loop is zo'n symptoom dat er van buiten overal hetzelfde uitziet, maar onder de motorkap heel verschillende oorzaken kan hebben. Je vult je wachtwoord in, de login slaagt gewoon aan de serverkant, en een fractie van een seconde later sta je weer op wp-login.php. Geen "wachtwoord fout"-melding. Niks kapot in je browser. Gewoon een stille bounce terug naar het begin. Snappen hoe dat werkt, is het verschil tussen een uur blind plugins uitzetten en rechtstreeks naar de ene instelling lopen die fout staat.

Wat een login redirect loop eigenlijk is

Een login redirect loop is een toestand waarin WordPress je inloggegevens accepteert, de auth-cookies netjes zet, je doorstuurt richting wp-admin/, en de volgende request vervolgens als anoniem behandelt en je terugkaatst naar wp-login.php. De controle van je wachtwoord is dus gelukt. De loop gaat niet over of je je wachtwoord nog weet. Hij gaat over de vraag of je browser en de server het eens worden over de cookie die bewijst dat je net bent ingelogd.

Dat ene detail is het belangrijkste om door te krijgen. Elke oplossing in dit hoekje van WordPress richt zich op één specifieke reden waarom die cookie-heen-en-terugreis is gebroken, en als je niet weet welke reden speelt, lijkt elke oplossing even waarschijnlijk.

Hoe WordPress je ingelogd houdt

Als je je gegevens POST naar wp-login.php, controleert WordPress ze en roept dan wp_set_auth_cookie() aan. Die functie schrijft drie aparte cookies in de response:

• wordpress_[hash] (de auth-cookie), beperkt tot /wp-admin/ en /wp-content/plugins/ via ADMIN_COOKIE_PATH en PLUGINS_COOKIE_PATH.
• wordpress_sec_[hash] (dezelfde auth-cookie, maar dan de secure variant), geschreven als de request over HTTPS binnenkomt. Dat is de SECURE_AUTH_COOKIE-naam.
• wordpress_logged_in_[hash] (de LOGGED_IN_COOKIE), beperkt tot de hele site via COOKIEPATH, voor alles buiten het admin-gebied.

Elk van die cookies gebruikt de COOKIE_DOMAIN-constante als domein-attribuut, zoals beschreven in de wp-config-referentie. Zet je COOKIE_DOMAIN niet zelf, dan laat WordPress het domein leeg, wat neerkomt op "whatever host de browser nu aan het praten is met". Dat detail wordt zo belangrijk.

Daarna stuurt WordPress een 302-redirect naar wp-admin/. De browser volgt die en stuurt alle cookies mee die bij het doel-host en -pad horen. Op de volgende paginalaad zoekt WordPress met wp_validate_auth_cookie() naar de auth-cookie. Is hij er en klopt hij, dan zie je het dashboard. Ontbreekt hij, dan zie je opnieuw het inlogscherm.

Waarom de loop ontstaat

De loop is de directe uitkomst van die stap die misgaat. WordPress weet niet dat hij een seconde geleden nog cookies heeft gezet voor jouw browser. Hij weet alleen hoe de huidige request eruitziet, en de huidige request ziet eruit als een anoniem bezoek. Dus stuurt hij je naar wp-login.php, die ziet dat je inloggegevens hebt verstuurd (een moment geleden, maar dat telt) en je doorstuurt naar het dashboard, wat er opnieuw anoniem uitziet, wat je weer naar wp-login.php stuurt, enzovoort.

Je browser geeft het op een gegeven moment op en laat ERR_TOO_MANY_REDIRECTS zien, of je landt stilletjes op de loginpagina zonder foutmelding. De server doet niks geks. Hij doet precies wat hem verteld is met de informatie die hij heeft.

De misconfiguraties die het cookie-rondje breken

Vier configuratie-foutjes dekken in mijn ervaring veruit het grootste deel van de login redirect loops in WordPress.

WP_HOME en WP_SITEURL komen niet overeen met de URL die de browser gebruikt. De auth-cookies worden geschreven voor het domein dat WordPress dénkt te zijn. Als WP_HOME op https://voorbeeld.nl staat maar je landt op https://www.voorbeeld.nl/wp-login.php, dan schrijft WordPress de cookie voor voorbeeld.nl en stuurt je browser de volgende request naar www.voorbeeld.nl, waar hij de cookie dus niet meestuurt. En andersom werkt precies zo: http:// in de database, https:// in de browser. Dit zie ik vaak direct na een HTTPS-migratie of een domeinverhuizing.

COOKIE_DOMAIN staat hardgecodeerd op een domein dat niet klopt. Sommige hardening-gidsen raden aan om COOKIE_DOMAIN expliciet te zetten. Als je een oude waarde overneemt bij een migratie, of de site is verhuisd zonder dat wp-config.php is bijgewerkt, dan klopt het domein-attribuut van de cookie niet meer met de echte hostnaam en laat de browser de cookie bij de volgende request gewoon vallen.

Een multisite-installatie deelt cookies over subsites zonder dat het goed staat. Multisite met domain mapping heeft juist de standaardwaarde van COOKIE_DOMAIN nodig (dus leeg), zodat elke site cookies voor zijn eigen hostnaam schrijft. Een afgedwongen COOKIE_DOMAIN op netwerkniveau breekt het cookie-rondje voor elke subsite behalve die ene waarvan het domein toevallig hardgecodeerd staat.

Een reverse proxy herschrijft de Host-header of laat het HTTPS-schema vallen. Cloudflare, nginx voor Apache en de meeste load balancers termineren TLS en praten dan plain HTTP met de origin. Vergeten ze X-Forwarded-Proto: https mee te sturen, dan denkt WordPress dat het een HTTP-request is en schrijft hij de niet-secure wordpress_[hash] in plaats van wordpress_sec_[hash]. De browser probeert vervolgens de secure cookie over HTTPS terug te sturen en dat matcht niet meer. Als diezelfde proxy ook nog de Host-header herschrijft, klopt het domein-attribuut op precies dezelfde manier niet meer als in het eerste geval.

Wat een login redirect loop níet is

Het meeste verspilde uitzoekwerk dat ik op dit probleem zie, komt doordat mensen het verwarren met naburige symptomen die een compleet andere oplossing hebben.

• Het is geen ERR_TOO_MANY_REDIRECTS op de voorkant van je site. Die fout is een redirect-loop op browser-niveau door HTTPS- of www-canonicalisatie en treft álle bezoekers, niet alleen ingelogde gebruikers. Is de voorkant zelf onbereikbaar en cirkelt hij tussen URL's, lees dan Too Many Redirects in WordPress. De login redirect loop gebeurt alléén nadat je je inloggegevens hebt verstuurd en speelt zich af tussen wp-login.php en wp-admin/.
• Het is geen wachtwoordprobleem. Als het wachtwoord fout is, toont WordPress een expliciete melding op het inlogscherm ("ERROR: The password you entered is incorrect"). Een redirect loop betekent juist dat de authenticatie is gelukt; een wachtwoord-fout betekent dat hij dat niet is. Krijg je een melding in het inlogformulier, lees dan waarom je niet kunt inloggen in WordPress en pak de "account"-tak.
• Het is niet de "cookies zijn geblokkeerd"-melding. Dat is een aparte veiligheidsrem waarbij WordPress een kortlopende probe-cookie op de loginpagina zet en weigert door te gaan als die niet terugkomt. Die loopt vast vóór de authenticatie, niet erna. Ander symptoom, ander mechanisme, andere oplossing. Krijg je die melding, lees dan cookies zijn geblokkeerd of worden niet ondersteund in WordPress.
• Het is geen rechten-probleem. Kom je wél in het dashboard en zie je dan "Je hebt geen toestemming om deze pagina te bekijken", dan is de login zelf gelukt. Dat is een capability-check en geen sessie-check, en met cookies heeft het niks te maken.

Waar je nu heen moet

Herken je het symptoom en wil je de stap-voor-stap oplossing, dan vind je de troubleshooting-variant onder errors: login redirect loop in WordPress loopt de oorzaken in diagnostische volgorde langs met verificatie-stappen. Laadt het dashboard juist gedeeltelijk en blijft het dan hangen in plaats van je direct weer uit te spugen, dan is dat een andere fout en hoort die thuis in WordPress-admin blijft laden na inloggen.