Vaša Magento zanka preusmerjanja verjetno ni VPN

V dnevniku dostopa vidite 302, trgovina se ne naloži prek VPN in sklep se napiše sam. Ta sklep je običajno na zanimiv način napačen. Odgovor preusmeritve zabeleži cilj, kamor je bil brskalnik poslan, in ne pove ničesar o tem, ali je težavo povzročil tunel, potrdilo ali aplikacija. Vrstica v dnevniku je začetek preiskave, ne njena ugotovitev.

302 pove kam, ne zakaj

Vnos v dnevniku dostopa zabeleži zahtevo, stanje in velikost ter običajno izpusti glavo Location, ki je pomembna. Ena preusmeritev je lahko povsem običajna: kanonično ime gostitelja, normalizacija končne poševnice, prehod na HTTPS. Potrebujete zaporedje, ker sta en skok in zanka različni okvari z različnima lastnikoma. Ponavljajoči se skoki med shemami kažejo na obdelavo URL in sheme. Skok na ime, ki ga brskalnik ne more razrešiti, kaže povsem drugam.

Nič od tega ni dokaz o VPN. Tunel je pot; preusmeritev je navodilo, ki ga je napisala aplikacija.

Ujemite verigo, ne vrstice v dnevniku

Uporabite omrežni pogled brskalnika in pri vsakem skoku zabeležite štiri polja: zahtevani URL, stanje, glavo Location in čas. Končajte s končnim odgovorom ali z napako povezave, ker je zanimiv primer skok, ki se nikoli ne dokonča. Naredite to enkrat na poti, ki deluje, in enkrat na tisti, ki ne uspe, z istim računom in isto navigacijo. Primerjava dveh verig je vredna več kot katera koli posamezna vrstica v dnevniku.

Ta zapis hranite zasebno. URL-ji nosijo identifikatorje seje, shranjena arhivska datoteka brskalnika pa nosi več, kot pričakujete. Preden karkoli prilepite v zahtevek, odstranite poizvedovalne nize.

Predstava aplikacije o lastnem URL-ju

Magento ustvarja absolutne URL-je iz konfiguracije, z obsegom na spletno mesto ali pogled trgovine. bin/magento config:show web/secure/base_url izpiše vrednost, v katero aplikacija verjame, in to je pogosto ime gostitelja, ki je ostalo od gradnje ali selitve, namesto tistega, ki ga je uporabil brskalnik. Če tam navaja notranjega gostitelja, je brskalnik poslan nekam, kamor ne more priti, in nobena sprememba tunela tega ne popravi.

Primerjajte varni in nevarni osnovni URL z javnimi imeni pred sabo. Neujemanje v katerem koli od njiju ustvari natanko tisto preusmeritev, v katero strmite.

Glave zaupanja vrednega proxyja so pogodba

Ko se TLS konča na uravnavalniku obremenitve, aplikacija vidi navaden HTTP in treba ji je povedati drugače. Nastavitev glave offloaderja poimenuje glavo, ki jo proxy nastavi, na primer posredovani protokol, in aplikacija ji zaupa pri odločitvah o shemi.

To zaupanje je pogodba z enim proxyjem, ne splošno dovoljenje. Sprejemanje glave od poljubnih odjemalcev omogoča komur koli, da zahteva shemo, zato spada le tja, kjer jo nastavi določen proxy. Če se ime glave in vedenje proxyja ne ujemata, aplikacija ustvari preusmeritve na shemo, ki je brskalnik ni nikoli uporabil, in zanka se zapre. Preverite konfiguracijo proxyja in nastavitev aplikacije skupaj, nato počistite predpomnilnik konfiguracije, da sprememba začne veljati.

Ko je zanka seja, ne pot

Veriga, ki se vedno vrne na prijavo, je običajno težava s piškotkom. Preverite, ali je bil piškotek seje izdan za ime gostitelja, ki ga je brskalnik dejansko uporabil, in ali je bil označen kot varen na povezavi, ki jo brskalnik šteje za varno. Piškotek, vezan na napačno domeno, ustvari zanko prijave, ki je videti natanko kot okvara usmerjanja.

Odpravite dokazano neujemanje pri njegovem lastniku, naj bo to osnovni URL, domena piškotka ali pogodba s proxyjem, nato znova preizkusite celotno navigacijo, namesto da gledate, kako en 302 izgine. Izklop zahtev HTTPS za prekinitev zanke zamenja preusmeritev za slabšo težavo. Ko je sprememba opravljena, preverite tunel ločeno: zahtevajte znan zasebni vir in potrdite, da prispe, da bo imela naslednja preusmeritev čisto izhodišče za primerjavo.