Ваша Magento петља преусмеравања вероватно није VPN

Видите 302 у дневнику приступа, продавница се не учитава кроз VPN и закључак се сам намеће. Тај закључак је обично погрешан на занимљив начин. Одговор преусмеравања бележи одредиште на које је прегледачу речено да оде и не говори ништа о томе да ли је проблем створио тунел, сертификат или апликација. Ред у дневнику је почетак истраге, а не њен налаз.

302 каже куда, а не зашто

Запис у дневнику приступа бележи захтев, статус и величину и обично изоставља заглавље Location које је важно. Једно преусмеравање може бити сасвим нормално: канонско име хоста, нормализација завршне косе црте, прелазак на HTTPS. Потребан вам је след, јер су један скок и петља различите грешке са различитим власницима. Поновљени скокови између шема упућују на обраду URL-а и шеме. А скок на име које прегледач не може да разреши упућује негде сасвим другде.

Ништа од тога није доказ о VPN-у. Тунел је пут; преусмеравање је упутство које је написала апликација.

Забележите ланац, а не ред из дневника

Користите мрежни приказ прегледача и забележите четири поља по скоку: тражени URL, статус, заглавље Location и време. Завршите или коначним одговором или грешком везе, јер је занимљив случај скок који се никада не доврши. Урадите то једном на путу који ради и једном на оном који не успева, са истим налогом и истом навигацијом. Поређење два ланца вреди више од иједног појединачног реда у дневнику.

Држите тај запис приватним. URL-ови носе идентификаторе сесије, а сачувана архива прегледача носи више него што очекујете. Уклоните низове упита пре него што било шта залепите у тикет.

Представа апликације о сопственом URL-у

Magento генерише апсолутне URL-ове из конфигурације, са дометом по веб-локацији или приказу продавнице. bin/magento config:show web/secure/base_url исписује вредност у коју апликација верује, а то је често име хоста заостало од изградње или миграције уместо оног које је прегледач користио. Ако тамо стоји интерно име хоста, прегледач се шаље негде куда не може да стигне и никаква промена тунела то не исправља.

Упоредите безбедни и небезбедни основни URL са јавним именима пред собом. Неусклађеност у било којем од њих производи управо преусмеравање у које гледате.

Заглавља поузданог проксија су уговор

Када TLS завршава на балансеру оптерећења, апликација види обичан HTTP и мора да јој се каже другачије. Поставка заглавља offloadera именује заглавље које прокси поставља, попут прослеђеног протокола, и апликација му верује при одлукама о шеми.

То поверење је уговор са једним проксијем, а не општа дозвола. Прихватање заглавља од произвољних клијената допушта свакоме да тврди шему, зато оно припада само тамо где га поставља одређени прокси. Ако се име заглавља и понашање проксија не слажу, апликација генерише преусмеравања на шему коју прегледач никада није користио и петља се затвара. Проверите конфигурацију проксија и поставку апликације заједно, затим испразните кеш конфигурације да промена ступи на снагу.

Када је петља сесија, а не рута

Ланац који се увек враћа на пријаву обично је проблем са колачићем. Проверите да ли је колачић сесије издат за име хоста које је прегледач стварно користио и да ли је означен као безбедан на вези коју прегледач сматра безбедном. Колачић везан за погрешан домен ствара петљу пријаве која изгледа управо као квар усмеравања.

Исправите доказану неусклађеност код њеног власника, било да је то основни URL, домен колачића или уговор са проксијем, па поново тестирајте целу навигацију уместо да гледате како један 302 нестаје. Искључивање HTTPS захтева ради прекидања петље мења преусмеравање за гори проблем. Када је промена готова, проверите тунел одвојено: затражите познати приватни ресурс и потврдите да стиже, како би следеће преусмеравање имало чисту основу за поређење.