Ihre Magento-Weiterleitungsschleife liegt wahrscheinlich nicht am VPN

Sie sehen 302 im Zugriffsprotokoll, der Shop lädt nicht über das VPN, und die Schlussfolgerung schreibt sich selbst. Diese Schlussfolgerung ist meist auf interessante Weise falsch. Eine Weiterleitungsantwort dokumentiert ein Ziel, zu dem der Browser geschickt wurde, und sagt nichts darüber, ob der Tunnel, das Zertifikat oder die Anwendung das Problem verursacht hat. Die Protokollzeile ist der Anfang der Untersuchung, nicht ihr Befund.

Ein 302 sagt wohin, nicht warum

Ein Zugriffsprotokolleintrag hält Anfrage, Status und Größe fest und lässt meist den entscheidenden Location-Header weg. Eine einzelne Weiterleitung kann völlig normal sein: ein kanonischer Hostname, eine Normalisierung des abschließenden Schrägstrichs, ein Wechsel zu HTTPS. Was Sie brauchen, ist die Abfolge, denn ein einzelner Sprung und eine Schleife sind verschiedene Fehler mit verschiedenen Verantwortlichen. Wiederholte Sprünge zwischen Schemata deuten auf die Behandlung von URL und Schema hin. Ein Sprung zu einem Namen, den der Browser nicht auflösen kann, deutet ganz woanders hin.

Nichts davon ist ein Beleg zum VPN. Der Tunnel ist ein Weg; die Weiterleitung ist eine Anweisung, die die Anwendung geschrieben hat.

Die Kette erfassen, nicht die Protokollzeile

Nutzen Sie die Netzwerkansicht des Browsers und notieren Sie vier Felder pro Sprung: die angeforderte URL, den Status, den Location-Header und die Zeit. Beenden Sie mit der endgültigen Antwort oder mit dem Verbindungsfehler, denn der interessante Fall ist der Sprung, der nie abgeschlossen wird. Tun Sie das einmal auf einem funktionierenden Weg und einmal auf dem fehlerhaften, mit demselben Konto und derselben Navigation. Zwei Ketten zu vergleichen ist mehr wert als jede einzelne Zeile in einem Protokoll.

Behandeln Sie diese Aufzeichnung vertraulich. URLs tragen Sitzungskennungen, und ein gespeichertes Browserarchiv enthält mehr, als Sie erwarten. Entfernen Sie Abfragezeichenfolgen, bevor Sie etwas in ein Ticket einfügen.

Die Vorstellung der Anwendung von ihrer eigenen URL

Magento erzeugt absolute URLs aus der Konfiguration, mit Geltungsbereich pro Website oder Store-Ansicht. bin/magento config:show web/secure/base_url gibt den Wert aus, den die Anwendung annimmt, und das ist oft ein Hostname aus einem Build oder einer Migration statt des vom Browser verwendeten. Wenn dort ein interner Host genannt wird, wird der Browser an einen Ort geschickt, den er nicht erreichen kann, und keine Tunneländerung behebt das.

Vergleichen Sie die sichere und die unsichere Basis-URL mit den öffentlichen Namen vor Ihnen. Eine Abweichung in einer der beiden erzeugt genau die Weiterleitung, auf die Sie schauen.

Vertrauenswürdige Proxy-Header sind ein Vertrag

Wenn TLS an einem Load Balancer endet, sieht die Anwendung reines HTTP und muss darüber informiert werden. Die Einstellung für den Offloader-Header benennt den Header, den der Proxy setzt, etwa das weitergeleitete Protokoll, und die Anwendung vertraut ihm bei Schemaentscheidungen.

Dieses Vertrauen ist ein Vertrag mit einem Proxy, keine allgemeine Erlaubnis. Den Header von beliebigen Clients zu akzeptieren, lässt jeden ein Schema behaupten, deshalb gehört er nur dorthin, wo ein bestimmter Proxy ihn setzt. Wenn Headername und Verhalten des Proxys nicht übereinstimmen, erzeugt die Anwendung Weiterleitungen zu einem Schema, das der Browser nie verwendet hat, und die Schleife schließt sich. Prüfen Sie Proxykonfiguration und Anwendungseinstellung gemeinsam und leeren Sie dann den Konfigurations-Cache, damit die Änderung wirksam wird.

Wenn die Schleife eine Sitzung ist, keine Route

Eine Kette, die immer wieder zur Anmeldung führt, ist meist ein Cookie-Problem. Prüfen Sie, ob das Sitzungs-Cookie für den Hostnamen ausgestellt wurde, den der Browser tatsächlich verwendet hat, und ob es auf einer vom Browser als sicher eingestuften Verbindung als sicher markiert wurde. Ein Cookie, das auf die falsche Domain beschränkt ist, erzeugt eine Anmeldeschleife, die genau wie ein Routingfehler aussieht.

Beheben Sie die nachgewiesene Abweichung bei ihrem Verantwortlichen, sei es die Basis-URL, die Cookie-Domain oder der Proxy-Vertrag, und testen Sie dann die gesamte Navigation erneut, statt zuzusehen, wie ein einzelner 302 verschwindet. HTTPS-Anforderungen abzuschalten, um die Schleife zu brechen, tauscht eine Weiterleitung gegen ein schlimmeres Problem. Wenn die Änderung erledigt ist, prüfen Sie den Tunnel getrennt: Fordern Sie eine bekannte private Ressource an und bestätigen Sie, dass sie ankommt, damit die nächste Weiterleitung eine saubere Vergleichsbasis hat.