Ваш цикл перенаправлений 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 ради разрыва цикла меняет перенаправление на более серьёзную проблему. Когда изменение сделано, проверьте туннель отдельно: запросите известный приватный ресурс и подтвердите, что он приходит, чтобы следующему перенаправлению было с чем чисто сравнивать.