Boucle de redirection derrière un reverse proxy : diagnostic et correction

Search Console signale des pages « avec redirection », donc non indexées. Testées dans un navigateur, ces mêmes pages s'ouvrent instantanément, en HTTPS, sans le moindre avertissement. L'écart entre les deux constats n'est pas une erreur de l'outil : c'est la signature d'un problème que seuls les robots voient.

L'architecture qui produit le défaut

La configuration en cause est aujourd'hui la norme. Un proxy inverse — Nginx, Traefik, un équilibreur de charge géré — reçoit le trafic sur le port sécurisé, déchiffre la connexion, puis transmet la requête au serveur d'application en clair sur le réseau interne.

Cette terminaison TLS au niveau du proxy présente de vrais avantages : les certificats sont centralisés, l'application n'a aucune gestion cryptographique à faire, et la mise à l'échelle est simplifiée. Mais elle introduit un décalage de perception : le serveur d'application ne voit que du HTTP.

Ce décalage est sans conséquence tant que l'application se contente de servir des pages. Il devient un défaut dès qu'elle doit construire une URL absolue — et c'est exactement ce que fait une redirection.

Le mécanisme précis

Le cas typique est la normalisation des barres obliques finales : le serveur est configuré pour rediriger /page/ vers /page, par cohérence des URL. La règle de réécriture construit l'URL de destination en interrogeant l'environnement pour savoir si la connexion est sécurisée.

Or cet indicateur reflète l'état de la connexion entre le proxy et l'application, pas celui de la connexion entre le visiteur et le proxy. Le proxy a déchiffré ; la liaison interne est en clair ; l'indicateur est donc à l'état « non sécurisé ».

La redirection produite pointe vers http://. Le navigateur ou le robot suit ce lien, atteint le proxy en HTTP, et le proxy — correctement configuré, lui — le redirige aussitôt vers HTTPS. La chaîne se referme sur la bonne page.

Le résultat est fonctionnel mais fautif : deux redirections pour une requête qui n'en méritait aucune, dont une étape en clair.

Le site n'est pas cassé. Il est légèrement faux, systématiquement, sur chaque URL concernée — et cette petite erreur répétée suffit à empêcher l'indexation.

Pourquoi le défaut passe inaperçu

Trois raisons se combinent pour rendre ce problème invisible en usage courant :

• Les navigateurs ne signalent rien. Ils suivent les redirections en silence et n'affichent que la destination finale. Le cadenas est présent, l'URL est en HTTPS, l'utilisateur ne perçoit qu'un chargement peut-être légèrement plus lent.
• Les outils de test de performance mesurent la page finale. La chaîne est parcourue avant la mesure, donc absente du rapport.
• Les journaux du serveur applicatif paraissent normaux. Ils enregistrent une requête et une réponse 301 — comportement attendu, aucune anomalie visible.

Seuls deux points d'observation révèlent le problème : une requête en ligne de commande sans suivi automatique des redirections, et le rapport d'indexation de Search Console.

Diagnostiquer en une commande

La vérification tient en une ligne. L'option d'affichage des entêtes uniquement, combinée au suivi des redirections, expose toute la chaîne :

curl -sSIL https://exemple.fr/page/ | grep -iE '^HTTP|^location'

Une chaîne saine affiche au plus une redirection, vers une destination en HTTPS. Une chaîne fautive ressemble à ceci :

HTTP/2 301
location: http://exemple.fr/page      <-- le protocole a été perdu
HTTP/1.1 301
location: https://exemple.fr/page     <-- le proxy rattrape l'erreur
HTTP/2 200

La deuxième ligne est le défaut. Tout le reste n'est que la conséquence.

Corriger au bon niveau

C'est le point où beaucoup de tentatives échouent : la correction doit être appliquée là où la redirection est produite, pas là où on suppose qu'elle l'est.

Cas 1 — la redirection vient d'une règle de réécriture du serveur web

C'est le cas le plus fréquent, et celui qui résiste aux corrections applicatives. La règle doit cesser de déduire le protocole et le forcer explicitement :

# Avant — le protocole est déduit de l'environnement, donc faux
RewriteRule ^(.+)/$ /$1 [R=301,L]

# Après — le protocole est imposé
RewriteRule ^(.+)/$ https://%{HTTP_HOST}/$1 [R=301,L]

Une variante consiste à s'appuyer sur l'entête transmis par le proxy pour connaître le protocole d'origine, ce qui permet de conserver une configuration valable aussi bien derrière un proxy qu'en accès direct. Cette approche suppose que le proxy transmet effectivement cet entête et qu'il l'écrase systématiquement, faute de quoi un client pourrait le falsifier.

Cas 2 — la redirection vient du framework

Si c'est le code applicatif qui génère la redirection, la correction consiste à déclarer les proxys de confiance, afin que le framework accepte de lire les entêtes transmis et reconstitue le protocole d'origine. La plupart des frameworks modernes disposent d'un mécanisme dédié ; il est presque toujours désactivé par défaut, pour de bonnes raisons de sécurité.

Point de vigilance : ne déclarer de confiance qu'aux adresses réellement contrôlées. Faire confiance à n'importe quelle source permettrait à un client de forger l'entête et de manipuler les URL générées par l'application.

Cas 3 — les deux

Rien n'interdit qu'une infrastructure cumule les deux mécanismes. La commande de diagnostic tranche : si la correction appliquée d'un côté ne change pas la chaîne observée, c'est que la redirection est produite de l'autre.

Après la correction

La chaîne doit disparaître entièrement. Une vérification s'impose sur plusieurs formes d'URL, car les règles de réécriture ne s'appliquent pas uniformément :

for u in / /page /page/ /rubrique/article/; do
  echo "── $u"
  curl -sSIL "https://exemple.fr$u" | grep -iE '^HTTP|^location'
done

Côté Search Console, la reprise n'est pas immédiate. Les URL concernées restent classées « Page avec redirection » jusqu'à leur prochaine exploration. Une demande de validation du correctif accélère le processus, mais il faut compter plusieurs jours avant que le rapport reflète l'état réel.

La règle générale à retenir

Derrière un proxy, toute information déduite de la connexion entrante est suspecte : le protocole, l'adresse IP du client, le nom d'hôte, le port. Ces valeurs décrivent la liaison interne entre le proxy et l'application, jamais celle du visiteur réel.

La conséquence pratique est simple : dans une configuration à terminaison TLS, une URL interne devrait être écrite en HTTPS absolu plutôt que reconstruite à partir de l'environnement. C'est moins élégant, cela déplaît aux tenants de la configuration universelle — mais c'est correct, et cela évite une classe entière de défauts silencieux qui ne se manifestent que dans les rapports d'indexation, plusieurs semaines après la mise en production.