Din Magento-omdirigeringsloop är förmodligen inte VPN:en

Du ser 302 i åtkomstloggen, butiken laddas inte via VPN:en och slutsatsen skriver sig själv. Den slutsatsen är oftast fel på ett intressant sätt. Ett omdirigeringssvar registrerar en destination som webbläsaren blev tillsagd att besöka, och det säger ingenting om huruvida tunneln, certifikatet eller applikationen skapade problemet. Loggrader är undersökningens början, inte dess fynd.

En 302 säger vart, inte varför

En post i åtkomstloggen registrerar begäran, statusen och storleken och utelämnar oftast den Location-header som betyder något. En enda omdirigering kan vara helt normal: ett kanoniskt värdnamn, en normalisering av det avslutande snedstrecket, ett byte till HTTPS. Det du behöver är sekvensen, eftersom ett enskilt hopp och en loop är olika fel med olika ägare. Upprepade hopp mellan scheman pekar på hantering av URL och schema. Ett hopp till ett namn som webbläsaren inte kan slå upp pekar någon helt annanstans.

Inget av detta är bevis om VPN:en. Tunneln är en väg; omdirigeringen är en instruktion som applikationen skrev.

Fånga kedjan, inte loggrader

Använd webbläsarens nätverksvy och notera fyra fält per hopp: den begärda URL:en, statusen, Location-headern och tiden. Avsluta med antingen det slutliga svaret eller anslutningsfelet, eftersom det intressanta fallet är hoppet som aldrig slutförs. Gör detta en gång på en fungerande väg och en gång på den misslyckade, med samma konto och samma navigering. Att jämföra två kedjor är värt mer än någon enskild rad i en logg.

Håll den registreringen privat. URL:er bär sessionsidentifierare, och ett sparat webbläsararkiv bär mer än du förväntar dig. Ta bort frågesträngar innan du klistrar in något i ett ärende.

Applikationens bild av sin egen URL

Magento genererar absoluta URL:er från konfigurationen, avgränsat per webbplats eller butiksvy. bin/magento config:show web/secure/base_url skriver ut det värde applikationen tror på, och det är ofta ett värdnamn som ligger kvar från en bygge eller migrering i stället för det webbläsaren använde. Om ett internt värdnamn anges där skickas webbläsaren någonstans där den inte kan komma, och ingen ändring av tunneln rättar det.

Jämför den säkra och den osäkra bas-URL:en med de offentliga namnen framför dig. En avvikelse i någon av dem ger exakt den omdirigering du stirrar på.

Headers från en betrodd proxy är ett avtal

När TLS slutar i en lastbalanserare ser applikationen ren HTTP och måste få veta något annat. Inställningen för offloader-headern namnger den header som proxyn sätter, till exempel det vidarebefordrade protokollet, och applikationen litar på den vid schemabeslut.

Det förtroendet är ett avtal med en proxy, inte ett allmänt tillstånd. Att acceptera headern från godtyckliga klienter låter vem som helst hävda ett schema, och därför hör den bara hemma där en utsedd proxy sätter den. Om headerns namn och proxyns beteende inte stämmer överens genererar applikationen omdirigeringar till ett schema som webbläsaren aldrig använde, och loopen sluts. Kontrollera proxykonfigurationen och applikationsinställningen tillsammans och töm sedan konfigurationscachen så att ändringen träder i kraft.

När loopen är en session, inte en rutt

En kedja som alltid återvänder till inloggning är oftast ett cookieproblem. Kontrollera om sessionscookien utfärdades för det värdnamn webbläsaren faktiskt använde, och om den markerades som säker på en anslutning som webbläsaren anser vara säker. En cookie som är begränsad till fel domän ger en inloggningsloop som ser exakt ut som ett routingfel.

Åtgärda den påvisade avvikelsen hos dess ägare, vare sig det är bas-URL:en, cookiens domän eller proxyavtalet, och testa sedan om hela navigeringen i stället för att titta på när en enda 302 försvinner. Att stänga av HTTPS-krav för att bryta loopen byter en omdirigering mot ett värre problem. När ändringen är gjord, kontrollera tunneln separat: begär en känd privat resurs och bekräfta att den anländer, så att nästa omdirigering har en ren baslinje att jämföra med.