Corriger les boucles de redirection : HTTPS, www et proxys inverses

Repérer l’URL qui se répète

Une boucle revient à une URL précédente : /shop → /store → /shop. Une longue chaîne peut toutefois se terminer correctement. Ouvrez la chaîne de redirections du rapport check.uk.app et comparez les adresses et les codes d’état. Un délai dépassé ou une limite de sauts ne prouve pas, à lui seul, l’existence d’une boucle.

Enregistrer la réponse publique

Remplacez example.com par une URL publique que vous contrôlez. Cette commande GET enregistre les en-têtes de chaque saut et le corps de la réponse finale. Elle s’arrête après dix redirections ou trente secondes. Dans Windows PowerShell, utilisez curl.exe. Ne partagez jamais de résultats de diagnostic contenant des jetons privés.

curl --silent --show-error --location --max-redirs 10 --max-time 30 --proto "=http,https" --proto-redir "=http,https" --dump-header headers.txt --output body.html https://example.com/

Identifier la couche en conflit

Examinez le CDN, le proxy, le serveur web et l’application. Une couche peut ajouter www tandis qu’une autre le supprime. Un proxy qui termine TLS peut transmettre du HTTP à une application qui redirige vers la même URL HTTPS publique. Choisissez l’hôte et le schéma canoniques, puis comparez les journaux à l’heure de la requête.

Transmettre le schéma par des proxys de confiance

Sur le proxy Nginx qui termine TLS, proxy_set_header X-Forwarded-Proto $scheme permet de communiquer le schéma externe. L’application ne doit faire confiance qu’aux proxys connus. Lors d’un saut HTTP via un proxy interne, $scheme n’est plus le schéma d’origine ; ne le conservez qu’à travers une chaîne explicitement approuvée. Ne considérez jamais comme fiables des en-têtes de transfert arbitraires fournis par le client.

Vérifier et prévoir un retour arrière

Sauvegardez les règles d’origine. Modifiez une couche, validez sa configuration et répétez le GET pour HTTP, HTTPS et les deux variantes du nom d’hôte, si elles sont configurées. Vérifiez le chemin et les paramètres de requête d’origine. Le parcours doit aboutir à la page prévue sans alterner entre les hôtes ni passer de HTTPS à HTTP.

Testez aussi la connexion et les formulaires : les codes de redirection peuvent influencer la méthode de requête. Comparez une nouvelle session de navigateur avec curl, car le cache du navigateur et HSTS peuvent modifier le comportement. Restaurez la règle sauvegardée si la navigation ne fonctionne plus. Effacer les cookies ne résout pas un conflit de redirections côté serveur.