Bucla de redirecționare Magento nu este probabil VPN-ul

Vedeți 302 în jurnalul de acces, magazinul nu se încarcă prin VPN și concluzia se scrie singură. Acea concluzie este de obicei greșită într-un mod interesant. Un răspuns de redirecționare înregistrează o destinație către care browserul a fost trimis, și nu spune nimic despre faptul că tunelul, certificatul sau aplicația au produs problema. Linia din jurnal este începutul investigației, nu constatarea ei.

Un 302 spune unde, nu de ce

O intrare din jurnalul de acces înregistrează cererea, starea și dimensiunea și de obicei omite antetul Location care contează. O singură redirecționare poate fi complet normală: un nume de gazdă canonic, o normalizare a barei oblice finale, o trecere la HTTPS. Aveți nevoie de succesiune, pentru că un singur salt și o buclă sunt defecțiuni diferite cu proprietari diferiți. Salturile repetate între scheme indică manipularea URL-ului și a schemei. Un salt către un nume pe care browserul nu îl poate rezolva indică cu totul altceva.

Nimic din toate acestea nu este dovadă despre VPN. Tunelul este o cale; redirecționarea este o instrucțiune scrisă de aplicație.

Capturați lanțul, nu linia din jurnal

Folosiți vizualizarea de rețea a browserului și notați patru câmpuri pe salt: URL-ul cerut, starea, antetul Location și ora. Încheiați cu răspunsul final sau cu eroarea de conexiune, pentru că cazul interesant este saltul care nu se finalizează niciodată. Faceți asta o dată pe o cale funcțională și o dată pe cea care eșuează, cu același cont și aceeași navigare. Compararea a două lanțuri valorează mai mult decât orice linie singură dintr-un jurnal.

Păstrați acel registru privat. URL-urile poartă identificatori de sesiune, iar o arhivă de browser salvată poartă mai mult decât vă așteptați. Eliminați șirurile de interogare înainte de a lipi ceva într-un tichet.

Ideea aplicației despre propriul URL

Magento generează URL-uri absolute din configurație, cu domeniu de aplicare pe site sau vizualizare de magazin. bin/magento config:show web/secure/base_url afișează valoarea în care crede aplicația, iar aceasta este adesea un nume de gazdă rămas de la o compilare sau o migrare în locul celui folosit de browser. Dacă acolo este numită o gazdă internă, browserul este trimis undeva unde nu poate ajunge, și nicio modificare a tunelului nu repară asta.

Comparați URL-urile de bază sigur și nesigur cu numele publice din fața dumneavoastră. O nepotrivire în oricare dintre ele produce exact redirecționarea la care vă uitați.

Antetele de proxy de încredere sunt un contract

Când TLS se termină la un echilibrator de încărcare, aplicația vede HTTP simplu și trebuie să i se spună altfel. Setarea antetului offloader numește antetul pe care îl setează proxy-ul, cum ar fi protocolul transmis, iar aplicația se bazează pe el în deciziile de schemă.

Acea încredere este un contract cu un singur proxy, nu o permisiune generală. Acceptarea antetului de la clienți arbitrari permite oricui să pretindă o schemă, de aceea aparține doar acolo unde o stabilește un proxy desemnat. Dacă numele antetului și comportamentul proxy-ului nu concordă, aplicația generează redirecționări către o schemă pe care browserul nu a folosit-o niciodată, iar bucla se închide. Verificați configurația proxy-ului și setarea aplicației împreună, apoi goliți memoria cache a configurației pentru ca modificarea să intre în vigoare.

Când bucla este o sesiune, nu o rută

Un lanț care revine mereu la autentificare este de obicei o problemă de cookie. Verificați dacă cookie-ul de sesiune a fost emis pentru numele de gazdă folosit efectiv de browser și dacă a fost marcat ca sigur pe o conexiune pe care browserul o consideră sigură. Un cookie limitat la domeniul greșit produce o buclă de autentificare care arată exact ca o defecțiune de rutare.

Remediați nepotrivirea demonstrată la proprietarul ei, fie că este URL-ul de bază, domeniul cookie-ului sau contractul cu proxy-ul, apoi retestați întreaga navigare în loc să priviți cum dispare un singur 302. Dezactivarea cerințelor HTTPS pentru a rupe bucla schimbă o redirecționare pe o problemă mai rea. Când modificarea este gata, verificați tunelul separat: cereți o resursă privată cunoscută și confirmați că ajunge, ca următoarea redirecționare să aibă o bază curată de comparație.