Nginx за обратным прокси перенаправляет HTTPS на HTTP

#Что означает и когда возникает ошибка

Отдельно проверьте, где именно возникает перенаправление: у внешнего прокси, у внутреннего Nginx или в приложении. Не доверяйте X-Forwarded-Proto, присланному любым клиентом из интернета.

#Причины и как их различить

#Пошаговая диагностика и исправление

1. Покажите цепочку ответа без браузераНа своём компьютере откройте терминал (Windows: PowerShell; Linux/macOS: «Терминал») и выполните curl -I --max-redirs 0 https://example.com/, заменив example.com на домен. Найдите HTTP/... и Location:. Команда HEAD может отличаться от GET; при сомнении проверьте GET с curl -sS -o /dev/null -D - https://example.com/. Не добавляйте в команду пароли и токены. Если Location на HTTP — запишите точный путь и время.
2. Определите, какой узел отвечает редиректомПо SSH откройте журналы и конфигурацию внешнего прокси и внутреннего Nginx. В sudo nginx -T проверьте return, rewrite, proxy_pass, proxy_set_header, server_name. Для контроля делайте запросы только к принадлежащему вам внутреннему адресу из доверенной сети, явно передавая Host. Не отправляйте внутренний адрес пользователям и не создавайте публичный доступ к административным портам.
3. Проверьте границу доверия для HTTPSЕсли TLS завершает внешний прокси, он должен устанавливать значение X-Forwarded-Proto исходя из реального входящего HTTPS, перезаписывая входящее значение, а не бесконтрольно передавая клиентское. Внутренний узел должен принимать такие сведения только от доверенного IP/сети. В типичной конфигурации Nginx, которая сама принимает HTTPS и проксирует приложение, уместно proxy_set_header X-Forwarded-Proto $scheme;; за другим TLS-терминатором $scheme может быть http, поэтому такая строка не универсальна.
4. Исправьте правило на конкретном узлеУстановите, кто отвечает за канонический HTTPS-адрес: обычно внешний публичный прокси. Удалите конфликтующий автоматический редирект на HTTP из внутреннего Nginx/приложения. Если приложение поддерживает список доверенных прокси и внешний URL, настройте их по документации именно этого приложения. Не делайте глобальный редирект по неподтверждённому $http_x_forwarded_proto: это открывает путь к подделке схемы.
5. Сделайте копию, проверьте и применитеПеред редактированием скопируйте действующий файл конфигурации в отдельный файл с датой и запишите, что меняли. Запустите sudo nginx -t; при успехе — sudo systemctl reload nginx. Если тест неуспешен, не перезагружайте службу, исправьте ошибку по указанной строке. Если после изменения возник цикл, восстановите копию и снова проведите тест.
6. Проверьте редиректы и содержимое страницыПовторите curl для http:// и https:// домена. Ожидается либо прямой ответ по HTTPS, либо короткий переход HTTP → HTTPS без обратного перехода. Откройте страницу в приватном окне и проверьте отсутствие смешанного содержимого по вкладке «Консоль» браузера. Если HTTP-ссылки остались только в HTML, их может генерировать приложение, не Nginx.
7. Команды для отдельных ситуацийВыберите только подходящий вариант. Это не одна последовательность: часть команд диагностирует проблему, а часть меняет настройки или данные.
   Выберите подходящий вариант — это не команды для последовательного выполнения

   Вариант 1Выполняется в терминале вашего компьютера без прав администратора; замените example.com на свой домен.

   Linux · Терминал (Bash)КомандаКопировать всёВыделить

   Выполняется в терминале вашего компьютера без прав администратора; замените example.com на свой домен. Не включайте секреты в адрес.

   curl -I --max-redirs 0 https://example.com/

   curl -sS -o /dev/null -D - https://example.com/

   Вариант 2Проверка синтаксиса после резервного копирования и правки.

   Linux · Терминал (Bash)КомандаНужен sudoКопировать всёВыделить

   Проверка синтаксиса после резервного копирования и правки. Только при успехе допускается reload.

   sudo nginx -t

   Вариант 3Пример лишь для случая, когда этот Nginx сам видит исходное HTTPS и принимает запросы на TLS; за внешним TL…

   NginxКопировать всёВыделить

   Пример лишь для случая, когда этот Nginx сам видит исходное HTTPS и принимает запросы на TLS; за внешним TLS-терминатором схему нужно получать через доверенную настройку.

   proxy_set_header Host $host;
   proxy_set_header X-Forwarded-Proto $scheme;

#Проверка результата

Успех: переходы ведут на один канонический HTTPS-адрес, заголовок Location не уводит на HTTP, и приложение создаёт HTTPS-ссылки.

#Если проблема осталась

Сохраните дату, точный URL без паролей и токенов, код ответа, обезличенные строки error.log и access.log за это время и перечень уже сделанных изменений. Сравните работу при обращении через публичный адрес и через внутренний балансировщик, если он есть. Если причину пока не удалось подтвердить, восстановите исходную конфигурацию из копии и передайте эти сведения администратору или разработчику приложения; не меняйте несколько параметров одновременно.