ERR_TOO_MANY_REDIRECTS derrière un CDN : les deux réglages qui bouclent ensemble.
Un CDN qui va chercher l'origine en HTTP simple et une origine qui force la redirection de HTTP vers HTTPS sont corrects chacun de leur côté et bouclent ensemble. Comment reconnaître la paire, la reproduire avec une seule requête et fermer les deux bouts.
Dans cet article 4 sections
- La paire à chercher quand un site derrière un CDN renvoie ERR_TOO_MANY_REDIRECTS : un mode SSL du CDN qui va chercher l'origine en HTTP simple, et une origine qui force la redirection de HTTP vers HTTPS sans vérifier ce que le proxy a déjà fait.
- Deux défauts, chacun inoffensif seul. Beaucoup d'origines servent du HTTP derrière un CDN qui termine le TLS, et beaucoup d'origines forcent le HTTPS. Seuls les deux ensemble bouclent.
- La boucle peut ne laisser aucune entrée dans le journal d'accès, parce que la couche qui répond la redirection n'enregistre pas forcément les requêtes ordinaires. Le silence ressemble à une absence de trafic et oriente la recherche dans la mauvaise direction.
- Reproduisez-la avec une seule requête vers l'origine, par le chemin que prennent les visiteurs, puis corrigez les deux bouts, pour que la boucle ne puisse pas se former quelle que soit la façon dont le site est exposé.
Activer le proxy du CDN devant une origine qui force le HTTPS suffit à démarrer la boucle. Les deux réglages sont raisonnables, et aucun ne casse rien à lui seul. Basculer un réglage et tester depuis un chemin qui contourne le CDN ressemble à une correction, alors que chaque vrai visiteur boucle encore.
Le mécanisme : deux bouts, une boucle
Le mode SSL du CDN était réglé sur "Flexible" : le navigateur parle HTTPS au CDN, mais le CDN parle HTTP simple à l'origine. Un réglage défendable en soi. Beaucoup d'origines servent du HTTP derrière un CDN qui termine le TLS.
La bordure de l'origine, de son côté, redirigeait de force chaque requête HTTP vers HTTPS, sans tenir compte du proxy : elle émettait la redirection sans vérifier l'en-tête qui dit que cette requête était déjà en HTTPS à la porte d'entrée. Le CDN va donc chercher en HTTP, l'origine répond « passe en HTTPS », la requête suivante du navigateur arrive au CDN en HTTPS, le CDN va chercher l'origine à nouveau en HTTP, et l'origine redirige à nouveau. Infini, par construction. Flexible seul est correct. La redirection forcée seule est correcte. Seuls les deux ensemble bouclent.
Le bug qui n'a rien journalisé
Si la couche qui répond la redirection n'enregistre pas les requêtes ordinaires, la boucle ne laisse rien dans le journal d'accès. Le silence ressemble à un trafic qui n'est jamais arrivé, et l'enquête va partout sauf au bon endroit. La règle : quand un bug ne laisse pas de journaux, arrêtez de chasser le silence et reproduisez le mécanisme.
Reproduisez le mécanisme
$ curl -I -H 'X-Forwarded-Proto: https' http://origin.example/
HTTP/1.1 301 Moved Permanently
Location: https://origin.example/
# told the origin the request was already HTTPS. it redirects anyway.Une seule requête reproduit la boucle, par le chemin que prennent les visiteurs. Un test depuis n'importe quel autre chemin passe et ne prouve rien.
Corrigez les deux bouts
| LE BOUT | LA CORRECTION |
|---|---|
| Le côté CDN | Mode SSL passé en "Full (Strict)" : le CDN parle un vrai HTTPS, vérifié, à l'origine. |
| L'UNE OU L'AUTRE CORRECTION CASSE LA BOUCLE. LES DEUX LA RENDENT IMPOSSIBLE.Le côté origine | La redirection rendue consciente du proxy : elle vérifie l'en-tête de protocole transmis et ne renvoie jamais une requête qui était déjà en HTTPS à la porte d'entrée. |
Corriger un seul bout d'une incompatibilité à deux bouts laisse une configuration « armée » qui attend le prochain changement. Fermez les deux bouts et il ne reste aucune combinaison qui tourne en rond : mettre le CDN en pause, changer de CDN, modifier l'origine, et la boucle n'a plus nulle part où se reformer.
“Aucun des deux bouts n'était cassé. Les deux ensemble l'étaient.”
Réponses directes
Comment corriger ERR_TOO_MANY_REDIRECTS derrière un CDN ?+
Vérifiez la paire, pas un seul réglage. Si le CDN va chercher votre origine en HTTP simple (un mode SSL de type "Flexible") et que votre origine force la redirection de HTTP vers HTTPS, ils bouclent. Passez le CDN en HTTPS complet et strict vers l'origine, et rendez la redirection de l'origine consciente du proxy.
Pourquoi ma boucle de redirection n'apparaît-elle pas dans les journaux d'accès ?+
La couche qui boucle n'enregistre pas forcément les requêtes ordinaires, donc la boucle est invisible. Ne chassez pas le silence. Reproduisez le mécanisme avec une seule requête vers l'origine et lisez ce qu'elle fait.
À quoi sert X-Forwarded-Proto ?+
Un proxy le positionne pour dire à l'origine quel protocole le visiteur a réellement utilisé. Une origine qui redirige HTTP vers HTTPS doit le vérifier, sinon elle renvoie des requêtes qui étaient déjà en HTTPS au niveau du proxy, et c'est ainsi que les boucles commencent.
Le mode Flexible SSL est-il mauvais ?+
C'est un compromis à bord tranchant : le trafic entre le CDN et l'origine n'est pas chiffré, et combiné à une redirection forcée sur l'origine, il boucle. Le mode complet et strict, avec un vrai certificat sur l'origine, supprime les deux problèmes.
Pourquoi cela a-t-il fonctionné quand je l'ai testé ?+
Un test qui ne passe pas par le CDN suit un chemin différent de celui de vos visiteurs. Reproduisez par le chemin exact qui échoue, en-têtes compris. C'est dans cette différence que se cache cette classe de bugs.
Aux prises avec un bug qui ne journalise rien ?
Le silence est aussi un symptôme. Nous reproduisons la défaillance, nous lisons les sources primaires et nous corrigeons les deux bouts.
Parler à un ingénieurVous êtes arrivé à la fin.
Mettez la lecture en pratique
Que faites-vous tourner ?
Parlez-nous de la charge de travail, du trafic et des exigences de reprise. Commencez par le configurateur de serveur, ou passez en revue les détails avec un ingénieur.
Écrit par les ingénieurs qui construisent et exploitent l'infrastructure qu'il décrit.Parler à un ingénieur