Проблема может быть связана с недостаточной осведомленностью о протоколе при кэшировании. Довольно типично, что HTTP-запрос, который должен быть перенаправлен на HTTPS-запрос, попадает в кеш, который безоговорочно перенаправляет пользователей на HTTPS-версию, даже если они действительно запрашивали HTTPS-версию.
Существуют различные способы исправить это в зависимости от типа используемого вами веб-сервера.
вывод лаклога
Но прежде чем мы сможем делать поспешные выводы, я хочу увидеть некоторые лаковое бревно вывод.
Я хотел бы увидеть вывод следующей команды, когда происходит цикл перенаправления:
лаклог -g запрос -q "ReqUrl eq '/'"
Предполагается, что проблема также возникает на домашней странице, которую мы добавили в качестве запроса VSL к лаковое бревно команда.
я заметил твой лакнкса вывод, но, к сожалению, он слишком ограничен с точки зрения вывода. лаковое бревно намного лучше для отладки, тогда как лакнкса просто.
Проверка гипотезы
Если петля перенаправления действительно вызвана отсутствием осведомленности о протоколе, мы можем вызвать проблему следующим образом:
- Бег
забанить лакадм obj.status "!=" 0 очистить кеш
- Вызовите простой URL-адрес HTTP веб-сайта, чтобы убедиться, что эта версия кэширована.
- Вызовите URL-адрес HTTPS веб-сайта, чтобы проверить, не застряли ли вы в цикле перенаправления.
Устранение проблемы
Если все тесты суммируются и гипотеза доказана, решение на самом деле довольно простое.
Если вы используете Apache в качестве веб-сервера, вы можете добавить следующее содержимое в свой .htaccess файл:
SetEnvIf X-Forwarded-Proto "https" HTTPS=on
Заголовок добавляется: X-Forwarded-Proto
В противном случае вы также можете добавить следующий код в свой файл VCL:
суб vcl_backend_response {
if(beresp.http.Vary) {
if(beresp.http.Vary !~ "X-Forwarded-Proto") {
set beresp.http.Vary = set beresp.http.Vary + ",X-Forwarded-Proto";
}
} еще {
установить beresp.http.Vary = "X-Forwarded-Proto";
}
}
Добавление X-Forwarded-Proto к Отличаться заголовок гарантирует, что Varnish создаст отдельные объекты в кеше для HTTP и для HTTPS.
Я также предполагаю, что ваш прокси-сервер TLS фактически отправляет X-Forwarded-Proto заголовок.
Обновление: проверка журналов
После некоторого обмена комментариями я получил несколько проницательных журналов через https://pastebin.com/QzPh1r5R которые объясняют, что происходит.
В ** << БеРек >> 951078 вы можете увидеть X-Forwarded-Proto: http заголовок. Это означает, что запрос был отправлен через обычный HTTP-запрос. Этот тип запроса должен привести к перенаправлению 301, и это происходит в соответствии со следующими строками журнала:
-- БереспПротокол HTTP/1.1
-- BerespStatus 301
-- BerespReason перемещен навсегда
-- BerespHeader Дата: Чт, 13 января 2022 г., 08:55:17 GMT
-- Сервер BerespHeader: Apache
-- Расположение BerespHeader: https://[домен лака]/
-- BerespHeader Content-Length: 238
-- BerespHeader Content-Type: text/html; кодировка = iso-8859-1
-- TTL RFC 120 10 0 1642064118 1642064118 1642064117 0 0 кэшируемый
Мало того, что происходит перенаправление, оно еще и кешируется на 120 секунд. Также интересно видеть, что нет Вари: X-Forwarded-Proto заголовок.
В более позднее время, * << Запрос >> 951080 транзакция всплывает в журналах. Мы видим следующие заголовки запроса:
- ReqHeader X-Forwarded-Proto: https
- Хост ReqHeader: [другой лаковый домен]
Итак, это HTTPS-запрос для другого домена Varnish, и по какой-то причине он приводит к попаданию в кэш, который возвращает Отличаться заголовок:
- RespHeader варьируются: Accept-Encoding, Cookie, X-Forwarded-Proto
- VCL_вызов HIT
- Хит 886585 90003.966201 10.000000 0.000000
Мало того, что вы видите попадание, вы также можете сделать вывод, что объект был вставлен в кеш транзакцией 886585.
Хотя хорошо иметь Отличаться заголовок, этот содержит Куки значение, которое опасно.Это означает, что в кэше будет храниться отдельный объект для каждого возможного значения cookie, представленного Varnish. Это довольно опасно, поэтому, пожалуйста, удалите Куки от Отличаться заголовок и придерживаться Варьировать: Accept-Encoding, X-Forwarded-Proto.
Последняя транзакция, на которую я смотрел, * << Запрос >> 951082. Оно имеет X-Forwarded-Proto: https заголовок запроса и не должен приводить к перенаправлению 301, но, к сожалению, приводит.
Ударять тег предоставляет некоторую интересную информацию:
- Хит 951078 82.391648 10.000000 0.000000
Объект, в который попали, изначально был вставлен в кеш транзакцией. 951078. Если вы обратили пристальное внимание, это было первое, что мы рассмотрели. Эта транзакция была только транзакцией HTTP, которая привела к перенаправлению 301.
И это именно тот объект, который возвращается. Таким образом, даже если вы запрашиваете HTTPS-контент, вы все равно перенаправляетесь, и именно поэтому вы попадаете в бесконечный цикл.
Если вы посмотрите на ответ, возвращаемый транзакцией 951082, вы не видите Отличаться заголовок:
- Респпротокол HTTP/1.1
- RespStatus 301
- RespReason перемещен навсегда
- Дата RespHeader: четверг, 13 января 2022 г., 08:55:17 по Гринвичу
- Сервер RespHeader: Apache
- Расположение RespHeader: https://[домен лака]/
- RespHeader Content-Length: 238
- Тип содержимого RespHeader: text/html; кодировка = iso-8859-1
- RespHeader X-лак: 951082 951078
- RespHeader Возраст: 37
- RespHeader Через: 1.1 лак (Лак/7.0)
Заключение: Пожалуйста, убедитесь, что X-Forwarded-Proto добавляется к вашему Отличаться заголовок. Это предотвратит застревание в цикле перенаправления.
