После TLS-терминации приложение зациклило redirect: передаём исходную схему

Клиент приходит к Nginx по HTTPS, а Nginx обращается к приложению по HTTP. Приложение видит незашифрованный вход и отправляет клиента на HTTPS. Клиент уже там, повторяет запрос и получает такое же перенаправление. Внешний сертификат при этом может быть полностью исправен: цикл возникает из-за потери информации об исходной схеме.

Сначала прочитайте Location

curl --max-time 10 -sS -D - -o /dev/null https://app.example/account

Без автоматического следования видно первый статус и заголовок Location. Если он возвращает на тот же HTTPS-адрес, сопоставьте ответ с журналом приложения. Проверьте также нормализацию слеша и домена: два уровня могут чередовать разные адреса, и тогда дело не только в схеме.

Не увеличивайте предел redirect и не отключайте HTTPS-перенаправление без понимания входной цепочки. Сначала выясните, кто завершает TLS и каким протоколом следующий уровень обращается к приложению. Для одного Nginx это один вариант; для CDN перед ним — уже другой.

Передайте схему от известной границы

location / {
    proxy_pass http://127.0.0.1:9000;
    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-Proto $scheme;
}

Для Nginx, который непосредственно принимает клиентский HTTPS, переменная scheme отражает нужную схему. Заголовок задаётся прокси заново, а не слепо сохраняется из внешнего запроса. Настройка приложения должна разрешать доверие forwarded-заголовкам только от известных прокси.

Конкретный переключатель доверия зависит от фреймворка. Без него приложение может продолжить считать запрос HTTP, даже когда заголовок уже приходит. С ним, но без ограничения источников, злоумышленник при прямом доступе к backend способен подменять сведения о внешнем запросе. Поэтому настройка состоит из передачи данных и определения доверенной границы.

Учитывайте несколько прокси

Если TLS завершается на внешнем балансировщике, а до Nginx идёт HTTP, его scheme будет http. Простое копирование примера потеряет исходный HTTPS. В такой схеме нужно принять информацию только от доверенного балансировщика, закрыть прямой обход и согласованно передать её дальше.

Не выбирайте произвольный первый или последний элемент списка forwarded-значений без знания топологии. Разные приложения трактуют цепочки по-разному. Опишите, кто создаёт заголовок, кто его заменяет и какие адреса приложение считает доверенными.

После настройки повторите исходный запрос без следования redirect. Ожидайте штатную страницу либо один осмысленный переход к каноническому адресу. Затем проверьте обычный HTTP-вход: он должен перенаправлять на HTTPS по принятой политике. Эти два теста подтверждают, что цикл устранён без потери требования шифрования.

Проверьте создаваемые абсолютные ссылки и secure-cookie, если приложение использует схему для их выбора. Устранение видимого redirect — первый результат; корректное представление внешнего запроса нужно и остальным частям приложения.

Соберите понятную модель пути HTTP-запроса. В курсе Linux и Bash для DevOps-инженеров предусмотрены сеть, HTTP и сопровождение учебного сервиса. Откройте программу, чтобы связывать ответ приложения с настройками промежуточных уровней и проверять результат по шагам.

Ещё по теме

• Nginx ходит к upstream по HTTPS: включаем SNI и проверку сертификата
• Загрузка файла получает 413: находим лимит тела запроса в Nginx и приложении