ERR_TOO_MANY_REDIRECTS: de doorverwijzingslus vinden en doorbreken

Wat de fout betekent

De browser heeft een pagina gevraagd en de server antwoordde “ga naar dit andere adres”. De browser ging erheen, en de server antwoordde opnieuw “ga ergens anders heen”, tot de bestemming weer het eerste adres was. Na een twintigtal sprongen stopt Chrome en toont “Deze pagina werkt niet” met de regel “example.com heeft je te vaak omgeleid” en de code ERR_TOO_MANY_REDIRECTS; Firefox zegt “De pagina wordt niet goed omgeleid”.

De server draait, het DNS werkt, het certificaat is geldig: de site draait in een kringetje. Bijna altijd ontstaat de lus uit twee regels die elkaar tegenspreken, bijvoorbeeld een die HTTPS afdwingt en een die terugstuurt naar HTTP, of een die www toevoegt en een die het weghaalt.

Veelvoorkomende oorzaken

1. Lus HTTP ↔ HTTPS met Cloudflare in de modus “Flexible”. Cloudflare spreekt HTTPS met de bezoeker maar HTTP met je server. De server ziet een HTTP-verzoek en stuurt het door naar HTTPS; Cloudflare brengt het terug naar HTTP; en zo verder. Veruit de meest voorkomende oorzaak.
2. Dubbele HTTPS-doorverwijzing. De webserver stuurt door naar HTTPS, en de applicatie doet dat ook (WordPress, een plugin, een gekopieerde .htaccess), maar met een voorwaarde die de TLS niet ziet omdat er een proxy voor staat.
3. Verkeerde WordPress-URL’s. siteurl en home in de database wijzen naar http:// of naar het domein zonder www, terwijl de server https://www. afdwingt: WordPress stuurt elk verzoek terug naar zijn eigen adres, de server stuurt het weer terug.
4. www ↔ zonder www. Een .htaccess voegt www toe, het server-blok van nginx of het paneel van de hostingprovider haalt het weg.
5. Twee keer return 301 of twee RewriteRules uit een oude configuratie, in een ingesloten bestand of in een .htaccess van een submap.
6. Een doorverwijzings- of cacheplugin met een oude regel, een geforceerde taal of een mobiele versie die naar zichzelf verwijst.

Als je bezoeker bent

Verwijder de cookies van die site (in de browserinstellingen, alleen voor dat domein) en probeer een incognitovenster of een andere browser. Blijft de fout, dan zit de lus op de server en kan alleen de eigenaar hem doorbreken: op je eigen apparaat valt niets te repareren.

Als het je eigen site is: eerst controleren

Open de Website down checker: die toont de keten van doorverwijzingen van buitenaf gezien, met elke code en elke bestemming. Hetzelfde vanaf de opdrachtregel:

# volg de doorverwijzingen en toon de headers (max. 10 sprongen)
curl -IL --max-redirs 10 https://example.com/

# één enkel verzoek, zonder te volgen: wat antwoordt de server?
curl -I https://example.com/
curl -I http://example.com/
curl -I https://www.example.com/

Lees de regels HTTP/… en location:. Stuurt https://example.com/ door naar hetzelfde adres, of naar http:// dat weer naar https:// doorstuurt, dan heb je de lus gevonden. De bestemming zegt wie hem veroorzaakt: http:// na een https://-verzoek wijst bijna altijd op een proxy of Cloudflare; www dat verschijnt en verdwijnt wijst op twee domeinregels.

Om te weten of het de webserver of de applicatie is, vraag je een statisch bestand op dat de applicatie niet aanraakt:

curl -I https://example.com/robots.txt

Antwoordt het statische bestand 200 en draait de homepage in een kringetje, dan zit de lus in de applicatie (WordPress, plugin). Wordt ook het statische bestand doorgestuurd, dan zit de lus in de webserver, de .htaccess of de proxy.

Oplossingen op je eigen server of hosting

1. Cloudflare: van “Flexible” naar “Full (strict)”

Zet in het Cloudflare-paneel, onder SSL/TLS, de modus op “Full (strict)”. Daarvoor is een geldig certificaat op de origin-server nodig; ontbreekt dat, maak het dan aan met certbot of met het origin-certificaat van Cloudflare. Blijf je voorlopig in “Flexible”, haal dan de HTTPS-doorverwijzing van de server weg en laat Cloudflare dat doen met “Always Use HTTPS”. Nooit allebei tegelijk.

2. Achter een proxy: doorverwijzen op basis van de juiste header

Met een proxy ervoor ziet de server altijd HTTP. De regel moet naar X-Forwarded-Proto kijken, niet naar de poort:

# .htaccess (Apache)
RewriteEngine On
RewriteCond %{HTTP:X-Forwarded-Proto} !https
RewriteCond %{HTTPS} !=on
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

In nginx laat je de doorverwijzing alleen staan in het blok dat op poort 80 luistert, en geen return 301 https://… in het 443-blok.

3. WordPress: siteurl en home gelijktrekken

Controleer de twee waarden en zet ze precies op het adres dat de server afdwingt (inclusief schema en www):

wp option get siteurl
wp option get home
wp option update siteurl https://www.example.com
wp option update home https://www.example.com

Zonder WP-CLI, in wp-config.php:

define('WP_HOME', 'https://www.example.com');
define('WP_SITEURL', 'https://www.example.com');

Staat WordPress achter een proxy, voeg dan in wp-config.php vóór de regel require_once ABSPATH . 'wp-settings.php'; toe:

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

4. Eén regel per domein

Kies één canonieke vorm (https://www.example.com of https://example.com) en laat één regel staan die erheen leidt: in de webserver, in de .htaccess of in het paneel van de hostingprovider, niet op twee plekken. In nginx:

server {
    listen 80;
    listen [::]:80;
    server_name example.com www.example.com;
    return 301 https://www.example.com$request_uri;
}

Zoek dubbele regels met grep -ri "RewriteRule\|return 301" /etc/nginx /var/www/example.com/.htaccess en in de submappen.

5. Doorverwijzings- en cacheplugins

Schakel de plugins voor doorverwijzing, cache, taal en beveiliging even uit (wp plugin deactivate plugin-naam, of door de map in wp-content/plugins/ te hernoemen). Verdwijnt de lus, schakel ze dan één voor één weer in en corrigeer de regel in de schuldige; leeg daarna de cache van de plugin en die van Cloudflare.

Als het probleem bij je hostingprovider ligt

Op shared hosting is de HTTPS- of www-doorverwijzing vaak een optie in het klantenpaneel, die bovenop je .htaccess komt. Schakel de optie of je eigen regel uit, niet allebei. Vind je de bron niet, stuur dan dit bericht:

Goedemiddag, sinds ongeveer 14:00 uur (UTC) geeft mijn website example.com ERR_TOO_MANY_REDIRECTS: curl -IL toont een lus tussen de http- en de https-versie van het domein. In mijn .htaccess staat maar één doorverwijzingsregel. Is er aan uw kant ook een HTTPS- of www-doorverwijzing actief, bijvoorbeeld vanuit het paneel of een proxy voor mijn webruimte?

Zodat het niet opnieuw gebeurt

Een doorverwijzingslus verschijnt bijna altijd direct na een wijziging: een nieuw certificaat, een plugin, een andere modus bij Cloudflare. Een HTTP-controle van buitenaf merkt het bij de eerste ronde en waarschuwt je vóór je bezoekers. Antwoordt de origin-server achter Cloudflare helemaal niet? Dat is een ander geval: fout 521 en 522. Stopt de browser juist bij het certificaat? Lees “Je verbinding is niet privé”. Voor een WordPress-site houdt het WordPress onderhoud op aanvraag updates en plugins in de gaten, zonder contract.

Down? Wij fixen het. Op je eigen server of op shared hosting met SSH-toegang herstelt de Quick Fix kleine configuratiefouten zoals een dubbele doorverwijzingsregel, met eerst een back-up, tegen een vaste prijs, 24 uur per dag, ook in het weekend; de Deep Fix neemt proxy, Cloudflare en WordPress-URL’s voor zijn rekening, per blok van 15 minuten; de schatting is de bovengrens.