Jūsu Magento pārvirzīšanas cilpa, iespējams, nav VPN

Piekļuves žurnālā redzat 302, veikals neielādējas caur VPN, un secinājums uzrakstās pats. Šis secinājums parasti ir nepareizs interesantā veidā. Pārvirzīšanas atbilde reģistrē galamērķi, uz kuru pārlūkam tika likts doties, un neko nepasaka par to, vai problēmu radīja tunelis, sertifikāts vai lietojumprogramma. Žurnāla rinda ir izmeklēšanas sākums, nevis tās atradums.

302 saka kur, nevis kāpēc

Piekļuves žurnāla ieraksts fiksē pieprasījumu, statusu un izmēru, un parasti izlaiž svarīgo Location galveni. Viena pārvirzīšana var būt pilnīgi normāla: kanonisks resursdatora nosaukums, beigu slīpsvītras normalizācija, pāreja uz HTTPS. Jums vajadzīga secība, jo viens lēciens un cilpa ir dažādi bojājumi ar dažādiem īpašniekiem. Atkārtoti lēcieni starp shēmām norāda uz URL un shēmas apstrādi. Bet lēciens uz nosaukumu, kuru pārlūks nevar atrisināt, norāda pavisam citur.

Neviens no šiem nav pierādījums par VPN. Tunelis ir ceļš; pārvirzīšana ir instrukcija, ko uzrakstīja lietojumprogramma.

Tveriet ķēdi, nevis žurnāla rindu

Izmantojiet pārlūka tīkla skatu un katram lēcienam pierakstiet četrus laukus: pieprasīto URL, statusu, Location galveni un laiku. Pabeidziet ar galīgo atbildi vai savienojuma kļūdu, jo interesantais gadījums ir lēciens, kas nekad netiek pabeigts. Dariet to vienreiz strādājošā ceļā un vienreiz neveiksmīgajā, ar to pašu kontu un to pašu navigāciju. Divu ķēžu salīdzināšana ir vērtīgāka par jebkuru atsevišķu žurnāla rindu.

Turiet šo ierakstu privātu. URL nes sesijas identifikatorus, un saglabāts pārlūka arhīvs nes vairāk, nekā gaidāt. Pirms kaut kā ielīmēšanas biļetē noņemiet vaicājuma virknes.

Lietojumprogrammas priekšstats par savu URL

Magento ģenerē absolūtos URL no konfigurācijas, ierobežotus pa vietni vai veikala skatu. bin/magento config:show web/secure/base_url izdrukā vērtību, kurai lietojumprogramma tic, un tā bieži ir resursdatora nosaukums, kas palicis no būvēšanas vai migrācijas, nevis tas, ko izmantoja pārlūks. Ja tur nosaukts iekšējais resursdators, pārlūks tiek sūtīts turp, kur tas nevar nokļūt, un nekādas tuneļa izmaiņas to nelabo.

Salīdziniet drošo un nedrošo bāzes URL ar publiskajiem nosaukumiem jūsu priekšā. Neatbilstība jebkurā no tiem rada tieši to pārvirzīšanu, uz kuru jūs skatāties.

Uzticama starpniekservera galvenes ir līgums

Kad TLS beidzas slodzes balansētājā, lietojumprogramma redz vienkāršu HTTP, un tai jāpasaka pretējais. Offloader galvenes iestatījums nosauc galveni, ko nosaka starpniekserveris, piemēram, pārsūtīto protokolu, un lietojumprogramma paļaujas uz to shēmas lēmumos.

Šī uzticēšanās ir līgums ar vienu starpniekserveri, nevis vispārēja atļauja. Galvenes pieņemšana no patvaļīgiem klientiem ļauj jebkuram pretendēt uz shēmu, tāpēc tā pieder tikai tur, kur to nosaka norādīts starpniekserveris. Ja galvenes nosaukums un starpniekservera uzvedība nesakrīt, lietojumprogramma ģenerē pārvirzīšanas uz shēmu, kuru pārlūks nekad nav izmantojis, un cilpa aizveras. Pārbaudiet starpniekservera konfigurāciju un lietojumprogrammas iestatījumu kopā, pēc tam notīriet konfigurācijas kešatmiņu, lai izmaiņas stātos spēkā.

Kad cilpa ir sesija, nevis maršruts

Ķēde, kas vienmēr atgriežas pie pierakstīšanās, parasti ir sīkfaila problēma. Pārbaudiet, vai sesijas sīfails tika izsniegts tam resursdatora nosaukumam, kuru pārlūks faktiski izmantoja, un vai tas tika atzīmēts kā drošs savienojumā, kuru pārlūks uzskata par drošu. Sīfails, kas piesaistīts nepareizam domēnam, rada pierakstīšanās cilpu, kas izskatās tieši kā maršrutēšanas kļūme.

Novērsiet pierādīto neatbilstību pie tās īpašnieka, vai tas būtu bāzes URL, sīkfaila domēns vai līgums ar starpniekserveri, pēc tam atkārtoti pārbaudiet visu navigāciju, nevis vērojiet, kā viens 302 pazūd. HTTPS prasību izslēgšana, lai pārtrauktu cilpu, apmaina pārvirzīšanu pret sliktāku problēmu. Kad izmaiņas ir veiktas, pārbaudiet tuneli atsevišķi: pieprasiet zināmu privātu resursu un apstipriniet, ka tas ierodas, lai nākamajai pārvirzīšanai būtu tīra atskaites līnija salīdzināšanai.