Te veel redirects: ERR_TOO_MANY_REDIRECTS-lussen oplossen | We.Inc
Plak uw redirectregels en zie ze stap voor stap draaien tot de lus zichtbaar wordt. Over HTTPS-lussen achter een proxy, www-lussen en cookielussen, met oplossingen.
ERR_TOO_MANY_REDIRECTS verschijnt als een pagina de browser steeds naar een ander adres stuurt dat hem uiteindelijk weer terugstuurt, zodat de keten nooit eindigt en de browser het opgeeft. De gebruikelijke boosdoeners zijn twee lagen die allebei HTTPS of www afdwingen, maar in tegengestelde richting. Los het op door precies één laag eigenaar te maken van elke redirect.
De lussen achter de meeste fouten met te veel redirects
Lus
Hoe hij ontstaat
Oplossing
HTTPS achter een proxy
De proxy praat gewone HTTP met de server, die opnieuw naar HTTPS redirect
Redirect op basis van X-Forwarded-Proto, of redirect alleen bij de proxy
www tegenover kaal domein
De ene laag voegt www toe, een andere haalt het weg
Kies één host en redirect er op één plek naartoe
Cookie- of loginlus
De loginpagina stuurt u naar de accountpagina, die u terugstuurt omdat de cookie nooit bleef hangen
Controleer de vlaggen Domain, Path en Secure van de cookie
Slash aan het eind
De ene regel voegt een slash toe, een andere haalt hem weg
Kies één vorm voor elke URL
Schrijf elke redirect die uw site uitvoert op een eigen regel als from -> to, voer het adres in waar u begint, en de simulator volgt de keten zoals een browser dat zou doen. Hij stopt als een adres terugkomt, als geen regel overeenkomt, of na 20 stappen, de limiet uit de Fetch Standard.
Som elke redirect op die u kent: serverconfig, hostingdashboard, CDN-regels, appcode.
Schrijf ze één per regel als volledige adressen, verbonden met ->.
Voer het adres in dat in de browser faalt en lees de lijst met stappen.
Verwijder of wijzig de regel die de keten terugstuurt naar een adres dat al bezocht is.
Wis de cookies van de site voordat u opnieuw test. Een verouderde cookie kan een loginlus in stand houden nadat de config al is hersteld.
Browsers cachen 301-redirects. Test oplossingen in een privévenster, of gebruik curl -I om elke response zonder cache te zien.
Redirect direct naar het eindadres. http://example.com hoort in één stap naar https://www.example.com te gaan, niet via twee.
Biedt een CDN of host een schakelaar om HTTPS af te dwingen, gebruik dan die of uw serverregel, nooit allebei zonder te controleren hoe ze samenwerken.
Veelgestelde vragen
Wat betekent 'heeft je te vaak omgeleid'?
Die melding en de foutcode ERR_TOO_MANY_REDIRECTS beschrijven hetzelfde: de site antwoordde met redirect na redirect en de browser stopte met volgen. Er is niets kapot op uw computer, al kan een verouderde cookie deel uitmaken van de lus.
Hoeveel redirects volgt een browser?
De Fetch Standard, die browsers implementeren, geeft een netwerkfout zodra het aantal redirects van een request 20 bereikt.
Waarom veroorzaakt het afdwingen van HTTPS een lus achter een proxy of CDN?
De bezoeker verbindt met HTTPS, maar de proxy stuurt het request via gewone HTTP door naar uw server. Uw server ziet HTTP en redirect naar HTTPS, en de cyclus herhaalt zich. Cloudflare documenteert precies deze lus voor zijn Flexible-versleutelingsmodus.
Lost cookies wissen te veel redirects op?
Alleen als een cookie deel uitmaakt van de lus, zoals een loginsessie die nooit wordt opgeslagen. Zit de lus in de serverregels, dan verandert cookies wissen niets.
Kan een redirectlus de SEO schaden?
Een pagina die in een lus vastzit laadt nooit, dus crawlers kunnen hem ook niet lezen. Los lussen snel op en houd redirectketens kort.
Waarom lussen in lagen ontstaan
Een moderne site heeft vaak drie of vier plekken die kunnen redirecten: het CDN, het hostingplatform, de webserver en de app. Elk wordt op een eigen scherm ingesteld, dus twee ervan kunnen het ongemerkt oneens zijn over het schema, de host of de slash aan het eind.
De simulator hierboven bootst precies dat na. Zet de regels van elke laag in dezelfde lijst en het meningsverschil wordt een zichtbare cyclus.
Het schemaprobleem bij proxy's
Als TLS eindigt bij een proxy of load balancer, ziet uw server alleen ooit gewone HTTP. Een regel die zegt dat alles op HTTP naar HTTPS moet worden geredirect, gaat dan af bij elk request, ook bij requests die voor de bezoeker HTTPS waren. Proxy's sturen het oorspronkelijke schema mee in de header X-Forwarded-Proto, dus de server moet in plaats daarvan die controleren.
Config die precies één keer redirect
nginx die zelf TLS afhandelt
Eén server-blok vangt elk HTTP-request op en stuurt het direct naar de eindhost.
nginx achter een proxy die TLS afhandelt
Redirect alleen als het oorspronkelijke schema van de bezoeker, door de proxy meegestuurd in X-Forwarded-Proto, http was.
Zie elke stap vanaf de command line
-I vraagt alleen headers op, -L volgt redirects. Elk blok in de uitvoer is één stap.
Simulator voor redirectlussen
Redirectregels, één per regel (from -> to)
Startadres
Stappen die de browser zou volgen
Lus: de keten keert terug naar {v}, dus de browser stopt met te veel redirects.
Geen lus: de keten eindigt bij {v} na {n} redirects.
De keten ging {n} stappen door zonder te eindigen, dus de browser geeft het op.
Geen regel komt overeen met het startadres, dus het laadt zonder redirect.