Twoja pętla przekierowań Magento prawdopodobnie nie wynika z VPN

Widzisz 302 w logu dostępu, sklep nie ładuje się przez VPN, a wniosek pisze się sam. Ten wniosek jest zwykle błędny w interesujący sposób. Odpowiedź przekierowania zapisuje cel, do którego przeglądarka miała się udać, i nic nie mówi o tym, czy problem stworzył tunel, certyfikat czy aplikacja. Wiersz logu jest początkiem śledztwa, a nie jego ustaleniem.

302 mówi gdzie, a nie dlaczego

Wpis w logu dostępu zapisuje żądanie, status i rozmiar, a zwykle pomija nagłówek Location, który ma znaczenie. Jedno przekierowanie może być całkowicie normalne: kanoniczna nazwa hosta, normalizacja końcowego ukośnika, przejście na HTTPS. Potrzebujesz sekwencji, bo pojedynczy skok i pętla to różne awarie z różnymi właścicielami. Powtarzające się skoki między schematami wskazują na obsługę URL i schematu. Skok do nazwy, której przeglądarka nie potrafi rozwiązać, wskazuje zupełnie gdzie indziej.

Nic z tego nie jest dowodem w sprawie VPN. Tunel to ścieżka; przekierowanie to instrukcja zapisana przez aplikację.

Przechwyć łańcuch, nie wiersz logu

Użyj widoku sieci przeglądarki i zanotuj cztery pola na skok: żądany URL, status, nagłówek Location i czas. Zakończ odpowiedzią końcową albo błędem połączenia, bo interesujący jest skok, który nigdy się nie kończy. Zrób to raz na ścieżce działającej i raz na zawodzącej, z tym samym kontem i tą samą nawigacją. Porównanie dwóch łańcuchów jest warte więcej niż jakikolwiek pojedynczy wiersz w logu.

Trzymaj ten zapis prywatnie. Adresy URL niosą identyfikatory sesji, a zapisane archiwum przeglądarki niesie więcej, niż się spodziewasz. Usuń ciągi zapytań, zanim cokolwiek wkleisz do zgłoszenia.

Wyobrażenie aplikacji o własnym URL

Magento generuje bezwzględne adresy URL z konfiguracji, z zakresem na witrynę lub widok sklepu. bin/magento config:show web/secure/base_url wypisuje wartość, w którą wierzy aplikacja, a bywa nią nazwa hosta pozostała po buildzie lub migracji, a nie ta użyta przez przeglądarkę. Jeśli wskazuje wewnętrzny host, przeglądarka trafia tam, gdzie nie może dojść, i żadna zmiana tunelu tego nie naprawi.

Porównaj bezpieczny i niebezpieczny bazowy URL z publicznymi nazwami przed sobą. Niezgodność w którymkolwiek z nich daje dokładnie to przekierowanie, na które patrzysz.

Nagłówki zaufanego proxy to umowa

Gdy TLS kończy się na równoważeniu obciążenia, aplikacja widzi zwykły HTTP i trzeba jej powiedzieć, że jest inaczej. Ustawienie nagłówka offloadera nazywa nagłówek ustawiany przez proxy, na przykład przekazany protokół, a aplikacja ufa mu przy decyzjach o schemacie.

To zaufanie jest umową z jednym proxy, a nie ogólnym pozwoleniem. Przyjmowanie nagłówka od dowolnych klientów pozwala każdemu twierdzić, że używa danego schematu, dlatego należy on tylko tam, gdzie ustawia go wyznaczone proxy. Jeśli nazwa nagłówka i zachowanie proxy się nie zgadzają, aplikacja generuje przekierowania na schemat, którego przeglądarka nigdy nie użyła, i pętla się zamyka. Sprawdź konfigurację proxy i ustawienie aplikacji razem, a potem wyczyść pamięć podręczną konfiguracji, aby zmiana zaczęła działać.

Gdy pętla jest sesją, a nie trasą

Łańcuch, który zawsze wraca do logowania, to zwykle problem z plikiem cookie. Sprawdź, czy plik cookie sesji został wydany dla nazwy hosta, której przeglądarka faktycznie użyła, i czy oznaczono go jako bezpieczny w połączeniu, które przeglądarka uważa za bezpieczne. Plik cookie przypisany do niewłaściwej domeny tworzy pętlę logowania wyglądającą dokładnie jak awaria routingu.

Napraw wykazaną niezgodność u jej właściciela, czy to bazowy URL, domena pliku cookie czy umowa z proxy, a następnie przetestuj całą nawigację od nowa, zamiast patrzeć, jak znika jeden 302. Wyłączanie wymagań HTTPS, aby przerwać pętlę, zamienia przekierowanie na gorszy problem. Gdy zmiana jest gotowa, sprawdź tunel osobno: poproś o znany prywatny zasób i potwierdź, że dociera, aby następne przekierowanie miało czystą linię bazową do porównania.