Votre boucle de redirection Magento n'est probablement pas le VPN

Vous voyez un 302 dans le journal d'accès, la boutique ne se charge pas à travers le VPN, et la conclusion s'écrit d'elle-même. Cette conclusion est généralement fausse d'une manière intéressante. Une réponse de redirection enregistre une destination vers laquelle le navigateur a été envoyé, et elle ne dit rien sur le fait que le tunnel, le certificat ou l'application soit à l'origine du problème. La ligne de journal est le début de l'enquête, pas son résultat.

Un 302 dit où, pas pourquoi

Une entrée du journal d'accès enregistre la requête, le statut et la taille, et omet souvent l'en-tête Location qui compte. Une seule redirection peut être parfaitement normale : un nom d'hôte canonique, une normalisation de la barre oblique finale, un passage au HTTPS. Ce qu'il vous faut, c'est la séquence, car un seul saut et une boucle sont des pannes différentes avec des responsables différents. Des sauts répétés entre schémas pointent vers le traitement des URL et du schéma. Un saut vers un nom que le navigateur ne peut pas résoudre pointe ailleurs entièrement.

Rien de tout cela n'est une preuve concernant le VPN. Le tunnel est un chemin ; la redirection est une instruction qu'a écrite l'application.

Capturez la chaîne, pas la ligne de journal

Utilisez la vue réseau du navigateur et notez quatre champs par saut : l'URL demandée, le statut, l'en-tête Location et l'heure. Terminez par la réponse finale ou par l'erreur de connexion, car le cas intéressant est le saut qui ne se termine jamais. Faites-le une fois sur un chemin qui fonctionne et une fois sur celui qui échoue, avec le même compte et la même navigation. Comparer deux chaînes vaut plus que n'importe quelle ligne isolée d'un journal.

Gardez cet enregistrement privé. Les URL portent des identifiants de session, et une archive de navigateur enregistrée porte plus que prévu. Supprimez les chaînes de requête avant de coller quoi que ce soit dans un ticket.

L'idée que l'application se fait de sa propre URL

Magento génère des URL absolues à partir de la configuration, par site web ou vue de magasin. bin/magento config:show web/secure/base_url affiche la valeur à laquelle l'application croit, et c'est souvent un nom d'hôte resté d'une compilation ou d'une migration plutôt que celui qu'a utilisé le navigateur. Si c'est un hôte interne qui est nommé, le navigateur est envoyé quelque part où il ne peut pas aller, et aucune modification du tunnel n'y remédie.

Comparez les URL de base sécurisée et non sécurisée aux noms publics qui vous font face. Une divergence dans l'une ou l'autre produit exactement la redirection que vous regardez.

Les en-têtes de proxy de confiance sont un contrat

Lorsque TLS se termine sur un répartiteur de charge, l'application voit du HTTP simple et doit être informée du contraire. Le réglage d'en-tête d'offloader nomme l'en-tête que le proxy définit, par exemple le protocole transmis, et l'application lui fait confiance pour les décisions de schéma.

Cette confiance est un contrat avec un proxy, pas une autorisation générale. Accepter l'en-tête de clients arbitraires permet à quiconque de revendiquer un schéma, et c'est pourquoi il ne doit exister que là où un proxy désigné le définit. Si le nom de l'en-tête et le comportement du proxy ne concordent pas, l'application génère des redirections vers un schéma que le navigateur n'a jamais utilisé, et la boucle se ferme. Vérifiez la configuration du proxy et le réglage de l'application ensemble, puis videz le cache de configuration pour que la modification prenne effet.

Quand la boucle est une session, pas une route

Une chaîne qui revient toujours à la connexion est généralement un problème de cookie. Vérifiez si le cookie de session a été émis pour le nom d'hôte que le navigateur a réellement utilisé, et s'il a été marqué sécurisé sur une connexion que le navigateur considère comme sécurisée. Un cookie limité au mauvais domaine produit une boucle de connexion qui ressemble exactement à une défaillance de routage.

Corrigez la divergence démontrée chez son responsable, que ce soit l'URL de base, le domaine du cookie ou le contrat du proxy, puis retestez toute la navigation au lieu de regarder un seul 302 disparaître. Désactiver les exigences HTTPS pour casser la boucle échange une redirection contre un problème pire. Une fois la modification faite, vérifiez le tunnel séparément : demandez une ressource privée connue et confirmez qu'elle arrive, afin que la prochaine redirection ait une base propre pour comparaison.