ERR_TOO_MANY_REDIRECTS: oorzaak van een redirectlus en de oplossing

Wat ERR_TOO_MANY_REDIRECTS betekent

Een redirect vertelt de browser "de pagina die u wilt zit ergens anders, ga daarheen." Eén enkele redirect, of zelfs twee of drie achter elkaar, is normaal: een kaal domein dat doorverwijst naar www, of een oude URL die doorverwijst naar de vervanging ervan. Een lus ontstaat wanneer een URL doorverwijst naar een tweede URL die terug doorverwijst naar de eerste, of naar zichzelf. Omdat de browser nooit een pagina bereikt die daadwerkelijk inhoud teruggeeft, breekt hij de keten af en toont de fout in plaats van voor altijd te blijven hangen.

Hoe de fout verschijnt

Chrome en Edge tonen "This page isn't working - redirected you too many times" met de foutcode ERR_TOO_MANY_REDIRECTS. Firefox toont "The page isn't redirecting properly." Safari zegt "Safari can't open the page because too many redirects occurred."

curl met de vlag -L volgt redirects op dezelfde manier als een browser, en het afdrukken van elke sprong toont precies waar de lus zich herhaalt:

curl -sIL https://example.com/ | grep -E "^(HTTP|location)"
HTTP/1.1 301 Moved Permanently
location: http://example.com/
HTTP/1.1 301 Moved Permanently
location: https://example.com/
HTTP/1.1 301 Moved Permanently
location: http://example.com/

Dat patroon, van http naar https en weer terug naar http, is verreweg de meest voorkomende vorm die deze fout aanneemt. curl stopt op zijn eigen standaardlimiet (50 redirects) in plaats van hem eindeloos te volgen, en de zich herhalende location-regels maken de lus meteen duidelijk zonder dat u een browser hoeft te openen.

Wat een redirectlus veroorzaakt

• Een mismatch tussen HTTP en HTTPS bij een proxy of CDN tegenover de origin. Dit is het klassieke geval. Staat de SSL/TLS-modus van Cloudflare op Flexible, dan beëindigt Cloudflare TLS bij de edge en maakt het via platte HTTP verbinding met de origin. Heeft de origin-server ook een regel die elk HTTP-verzoek doorverwijst naar HTTPS (een gebruikelijke beveiligingsstandaard), dan stuurt de origin de browser terug naar HTTPS, downgraadt Cloudflare bij de volgende sprong weer naar HTTP, en vechten de twee instellingen eindeloos met elkaar.
• Regels voor www en niet-www die naar elkaar wijzen. De ene regel verwijst het kale domein door naar www, en een aparte regel, vaak later toegevoegd door een andere beheerder of plugin, verwijst www weer terug naar het kale domein.
• Een mismatch in de siteurl of home van WordPress. Komt de geconfigureerde URL van de site in de database niet overeen met de URL die bezoekers daadwerkelijk gebruiken (een achtergebleven staging-URL, een schemamismatch na het toevoegen van SSL), dan blijft WordPress doorverwijzen naar de geconfigureerde waarde.
• Cookies die de server verwacht maar nooit ontvangt, of een loginredirect die stilzwijgend faalt. Een pagina die niet-geauthenticeerde bezoekers doorverwijst naar een loginstap, die vervolgens terugverwijst naar dezelfde pagina omdat de sessiecookie nooit werd ingesteld (vaak geblokkeerd door de regels voor cookies van derden van een browser of een ontbrekend Secure/SameSite-attribuut), loopt eindeloos rond.
• Regels voor een slash aan het eind of een taalprefix die botsen. De ene regel voegt een slash aan het eind toe, een andere haalt hem weg; de ene regel voegt een taalprefix toe op basis van de browserlocale, een andere haalt hem weg voor canonieke URL's, en de twee heffen elkaar op.
• Een cachinglaag die een verouderde redirect serveert. Een CDN of reverse proxy cachete een oude 301 die wees naar een URL die, inmiddels gewijzigd, terugverwijst naar de oorspronkelijke.

Hoe u vaststelt wiens fout het is

Gebeurt de lus bij elke bezoeker op elk netwerk, dan is het een configuratieprobleem bij de server of CDN, niets lokaals. Gebeurt het alleen bij u, wis dan eerst de cookies voor de site, aangezien een slechte of verlopen sessiecookie een groot deel van de lussen bij één bezoeker veroorzaakt. Een HTTP-controle vanaf meerdere locaties beslecht dit in één verzoek: verschijnt dezelfde redirectketen (of dezelfde storing) vanaf elke locatie, dan zit de oplossing aan de serverkant.

Hoe u ERR_TOO_MANY_REDIRECTS oplost

Bent u de bezoeker

1. Wis de cookies voor de site. Klik in Chrome op het slotje of tune-icoon naast de adresbalk, open sitegegevens, en wis cookies en sitegegevens alleen voor dat domein.
2. Probeer een incognito- of privévenster. Dit sluit een browserextensie of een opgeslagen cookie als oorzaak uit zonder uw gewone profiel aan te raken.
3. Probeer een ander netwerk, zoals mobiele data in plaats van wifi. Sommige proxy's op bedrijfs- of providerniveau herschrijven verzoeken op manieren die alleen op dat netwerk een lus veroorzaken.
4. Wis de cache van de browser voor het geval een redirectantwoord zelf werd gecachet van voordat de site werd hersteld.

Beheert u de site

1. Controleer de SSL-modus van uw CDN tegenover de redirectregel van uw origin. Open in Cloudflare SSL/TLS en zet de modus op Full of Full (strict), niet Flexible, wanneer de origin HTTP doorverwijst naar HTTPS. Full laat de origin nog steeds een zelfondertekend certificaat gebruiken; Full (strict) vereist een geldig certificaat.
2. Vertrouw op de doorgegeven protocolheader in plaats van blind door te verwijzen. Staat er een proxy voor uw app, dan moet de origin doorverwijzen op basis van X-Forwarded-Proto, niet op de rauwe verbinding, die van achter de proxy altijd HTTP lijkt. Op nginx:

   if ($http_x_forwarded_proto = "http") {
       return 301 https://$host$request_uri;
   }

   en zorg dat de CDN of loadbalancer die header ook daadwerkelijk op elk verzoek instelt.
3. Controleer uw redirectregels op volgorde, inclusief .htaccess, nginx server-blocks, applicatieniveau-middleware, en elke CDN-pageregel, op twee regels die naar elkaar wijzen. Een veelvoorkomend Apache-patroon dat achter een proxy in een lus terechtkomt:

   RewriteCond %{HTTPS} off
   RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

   faalt op dezelfde manier als het nginx-voorbeeld hierboven, aangezien %{HTTPS} de verbinding leest die de proxy maakt, niet die van de bezoeker; controleer in plaats daarvan %{HTTP:X-Forwarded-Proto}.
4. Herstel de site-URL van WordPress indien van toepassing: bevestig in wp-admin > Settings > General dat zowel het WordPress-adres als het site-adres overeenkomen met de URL die bezoekers daadwerkelijk gebruiken, protocol inbegrepen. Is het adminpaneel zelf onbereikbaar door de lus, stel WP_HOME en WP_SITEURL dan rechtstreeks in wp-config.php in.
5. Kies één canonieke vorm en verwijs al het andere er in één keer naartoe, niet in een keten: www of niet-www, slash aan het eind of niet, één regel per beslissing in plaats van meerdere regels die na verloop van tijd door verschillende tools over elkaar heen zijn gelegd.
6. Ledig de CDN-cache na het herstellen van de regel, aangezien een gecachete 301 of 302 het oude antwoord blijft sturen totdat die verloopt of geledigd wordt.

Gerelateerde fouten

• 3xx-redirectstatuscodes legt uit wat 301, 302, 303, 307 en 308 elk betekenen.
• 301 versus 302 behandelt wanneer een redirect permanent moet zijn versus tijdelijk, wat van belang is voor zoekmachines en caching, niet alleen voor lussen.

Hoe u ERR_TOO_MANY_REDIRECTS voorkomt

Een redirectlus wordt vrijwel altijd geïntroduceerd door een configuratiewijziging: een nieuwe CDN, een nieuw SSL-certificaat, een plugin-update, of een migratie die de site-URL raakte. Een HTTP-controle die de responscode bewaakt en redirects volgens schema volgt vangt een lus op zodra die verschijnt, vanaf 300+ meetpunten in 158 steden, in plaats van te wachten op een supportticket. HostTracker monitort websites sinds 2004 en kan waarschuwen via e-mail, sms, spraakoproep, Slack, Telegram en meer zodra een controle begint te falen.

Veelgestelde vragen

Hoeveel redirects staat een browser toe voordat hij het opgeeft?

Chrome en op Chromium gebaseerde browsers stoppen bij ongeveer 20. De standaardlimiet van curl met -L is 50. Het exacte aantal verschilt per client, maar elk ervan stopt uiteindelijk in plaats van een lus voor altijd te volgen.

Waarom gebeurt de lus pas vlak nadat ik naar Cloudflare (of een andere CDN) verhuisde?

Vrijwel altijd de SSL/TLS-modus. Flexible-modus spreekt platte HTTP met de origin; staat de origin op HTTPS, dan verwijzen de twee kanten elkaar eindeloos door. Overschakelen naar Full of Full (strict) lost het meestal meteen op.

Kan een browserextensie dit veroorzaken?

Ja, vooral extensies die HTTPS afdwingen, verzoeken herschrijven, of cookies beheren. Testen in een incognitovenster met extensies uitgeschakeld sluit dit snel uit.

Heeft dit invloed op SEO?

Ja. Crawlers van zoekmachines geven een redirectlus net zo snel op als een browser, en een URL die in een lus zit wordt niet geïndexeerd of valt uit de index als hij vroeger wel werkte.

Ik zie de fout alleen op één specifieke pagina, niet op de hele site. Wat is daar anders aan?

Controleer op een paginaspecifieke regel: een pagina die inloggen vereist, een gecachete oude redirect voor precies die URL, of een mismatch in slash aan het eind die alleen op die route bestaat. Vergelijk de exacte redirectketen voor die URL met een werkende pagina via curl -sIL.

Is één enkele redirect (zoals niet-www naar www) iets om te herstellen?

Nee, één redirect op zichzelf is normaal en verwacht. Alleen een zich herhalende keten die nooit een uiteindelijke 200-antwoord bereikt is het probleem dat deze fout beschrijft.