Ваш цикл перенаправлень 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, і йому треба сказати про протилежне. Налаштування заголовка offloader називає заголовок, який задає проксі, наприклад переданий протокол, і застосунок довіряє йому під час рішень про схему.

Ця довіра — договір з одним проксі, а не загальний дозвіл. Приймання заголовка від довільних клієнтів дозволяє будь-кому заявляти схему, тому він доречний лише там, де його задає призначений проксі. Якщо назва заголовка й поведінка проксі не збігаються, застосунок генерує перенаправлення на схему, яку браузер ніколи не використовував, і цикл замикається. Перевірте конфігурацію проксі й налаштування застосунку разом, потім скиньте кеш конфігурації, щоб зміна набула чинності.

Коли цикл — це сесія, а не маршрут

Ланцюжок, який завжди повертається до входу, зазвичай означає проблему з cookie. Перевірте, чи cookie сесії видано для того імені хоста, яке браузер справді використав, і чи позначено його як безпечний на з'єднанні, яке браузер вважає безпечним. Cookie, прив'язаний до неправильного домену, дає цикл входу, що виглядає точно як збій маршрутизації.

Усуньте доведену розбіжність у її власника, чи це базовий URL, домен cookie чи договір із проксі, а потім повторно перевірте всю навігацію, замість того щоб дивитися, як зникає один 302. Вимкнення вимог HTTPS заради розриву циклу міняє перенаправлення на серйознішу проблему. Коли зміну зроблено, перевірте тунель окремо: запитайте відомий приватний ресурс і підтвердьте, що він надходить, щоб наступному перенаправленню було з чим чисто порівнювати.