Как настроить редирект с HTTPS на HTTP в Nginx и когда это нужно | AdminWiki
Logo

Как настроить редирект с HTTPS на HTTP в Nginx и когда это нужно

05 сентября 2026 11 мин. чтения
Содержание статьи

Короткий ответ: обратный редирект допустим только для ограниченных сценариев

Редирект с HTTPS на HTTP в Nginx настраивают в блоке server, который слушает порт 443. Для временного переключения используйте return 302 http://example.com$request_uri; или 307. Код 301 уместен после подтверждения постоянного перехода, поскольку браузеры и поисковые системы могут долго кэшировать этот ответ.

HTTPS обычно нужно сохранять. Переход на HTTP допустим на изолированном тестовом стенде, во внутреннем сервисе с ограниченным доступом, при краткой миграции или при интеграции с legacy-приложением без поддержки TLS. HTTP-порт обязан отдавать ресурс или проксировать запрос в приложение. Если порт 80 перенаправляет клиента обратно на HTTPS, возникнет цикл.

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

Когда схема HTTPS → HTTP действительно уместна

  • Тестовая или предпродакшен-среда. Стенд доступен только через VPN, private network или ограниченный список IP-адресов. На нем нет реальных учетных записей, токенов и пользовательских данных.
  • Внутренний сервис. Доступ ограничен сегментом корпоративной сети, а передаваемые данные не относятся к чувствительным. Даже в таком случае лучше ограничить доступ firewall-правилами.
  • Временная миграция. Нужно быстро вернуть доступ к приложению, пока исправляют сертификат, цепочку прокси или TLS-настройки. Для такого случая выбирают 302 либо 307 и заранее определяют срок отката.
  • Legacy-компонент. Старое приложение или устройство принимает HTTP и не умеет TLS. Публичный входной контур лучше оставить на HTTPS, а HTTP использовать только в изолированном внутреннем сегменте.

Для отдельного стенда полезно развернуть независимый виртуальный сервер, чтобы правила downgrade не попали в production-конфигурацию. Облачную инфраструктуру для временных сред можно подобрать через Timeweb Cloud, если требуется быстро выделить отдельный VDS/VPS и изолировать тестовый домен.

Когда от редиректа нужно отказаться

  • На публичном сайте, базе знаний, интернет-магазине или клиентском портале.
  • При входе пользователей по логину и паролю, SSO, OAuth callback, работе с платежами и личными кабинетами.
  • Когда API передает bearer-токены, ключи доступа, cookies сессии или персональные данные.
  • Когда сервис открывается через публичный Wi-Fi, мобильную сеть или любую сеть без полного доверия.
  • Когда причина проблемы сводится к неверному сертификату, устаревшему TLS или ошибочной конфигурации proxy. В такой ситуации исправляют HTTPS, а не снижают защиту.

Если задача связана с сертификатом, HSTS или защитными заголовками, проверьте конфигурацию по инструкции ручной установки SSL-сертификата в Nginx и Apache. Это часто устраняет исходную причину без перехода на HTTP.

Как работает редирект HTTPS на HTTP в Nginx

Клиент сначала устанавливает TLS-соединение с портом 443 и отправляет HTTPS-запрос. Nginx принимает его, возвращает ответ 301, 302 или 307 с заголовком Location: http://.... После этого браузер создает новое соединение с HTTP-портом, обычно с 80.

Редирект не передает запрос в приложение и не преобразует соединение внутри Nginx. Он сообщает клиенту новый URL. Поэтому сервер на целевом HTTP-порту должен быть доступен, правильно выбирать виртуальный хост и отдавать нужный маршрут.

Роль server block для порта 443

Правило для всего домена размещают на уровне server с listen 443 ssl. В этом блоке остаются рабочие пути к сертификату и ключу: TLS-соединение требуется, чтобы сервер успел вернуть HTTP-адрес клиенту.

Для одного legacy-маршрута правило размещают в location. Остальная часть сайта продолжит работать по HTTPS. Такой вариант уменьшает область риска и обычно подходит для временной диагностики.

Что происходит с путем и query string

Переменная $request_uri сохраняет путь и строку параметров в исходном виде. Запрос https://example.com/report?id=42&format=csv станет http://example.com/report?id=42&format=csv.

Для публичного домена безопаснее указать фиксированный hostname: http://example.com$request_uri. Вариант с $host допустим, когда server_name строго ограничен и обработка неизвестных Host-заголовков продумана. Если HTTP-сервис слушает нестандартный порт, добавьте его явно: http://example.com:8080$request_uri.

Настройка редиректа с HTTPS на HTTP в Nginx

Используйте return для прямого перехода. Конфигурация читается проще, чем правила rewrite, и не смешивает редирект с логикой backend-приложения. Разницу между HTTP-редиректом и proxy_pass полезно сверить в материале о перенаправлении портов в Nginx.

Полный редирект виртуального хоста

Этот пример принимает HTTPS-запросы для домена и временно переводит их на HTTP с сохранением URI:

server {
    listen 443 ssl;
    server_name example.com www.example.com;

    ssl_certificate     /etc/nginx/ssl/example.com/fullchain.pem;
    ssl_certificate_key /etc/nginx/ssl/example.com/privkey.pem;

    return 302 http://example.com$request_uri;
}

После проверки замените 302 на 301, только если схема HTTP станет постоянной. Код 307 лучше подходит для временного перехода, когда нужно сохранить метод и тело запроса: например, для POST при техническом переключении API. Для обычной браузерной навигации чаще используют 302.

Не используйте 301 как диагностический код. Он может остаться в кеше браузера и усложнить повторный возврат на HTTPS.

Редирект только отдельного пути

Следующая конфигурация переводит на HTTP только все маршруты внутри /legacy/. Остальные HTTPS-запросы можно проксировать в приложение или обслуживать статически.

server {
    listen 443 ssl;
    server_name example.com;

    ssl_certificate     /etc/nginx/ssl/example.com/fullchain.pem;
    ssl_certificate_key /etc/nginx/ssl/example.com/privkey.pem;

    location ^~ /legacy/ {
        return 307 http://example.com$request_uri;
    }

    location / {
        proxy_pass http://app_upstream;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-Proto https;
    }
}

Префикс ^~ /legacy/ охватывает вложенные пути, например /legacy/status. Проверьте регулярные location в подключаемых файлах: они не должны перехватывать этот маршрут неожиданным правилом.

Как применить конфигурацию без остановки Nginx

  1. Сохраните резервную копию изменяемого файла виртуального хоста.
  2. Проверьте синтаксис: sudo nginx -t.
  3. Примените конфигурацию только при успешной проверке: sudo systemctl reload nginx.
  4. Сразу проверьте заголовок Location и доступность HTTP-адреса.

Не выполняйте reload после ошибки nginx -t. Сначала исправьте файл, повторите проверку и убедитесь, что подключаемые конфигурации не содержат конфликтующих серверных блоков.

Как избежать циклического редиректа HTTPS → HTTP → HTTPS

Цикл появляется, когда HTTPS-блок отправляет клиента на HTTP, а HTTP-блок безусловно возвращает его на HTTPS. Браузер в такой схеме показывает ошибку вида Too many redirects, а приложение остается недоступным.

Проверка правил для портов 80 и 443

Для обратного редиректа блок на 443 должен возвращать HTTP-URL. Блок на 80 обязан отдавать контент или проксировать его в backend без правила return 301 https://....

server {
    listen 80;
    server_name example.com www.example.com;

    location / {
        proxy_pass http://app_upstream;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-Proto http;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }
}

Проверьте все файлы из sites-enabled, conf.d и include-файлы. Особое внимание уделите повторяющимся server_name, default_server и старым правилам принудительного HTTPS. Конфигурация для массового перехода HTTP на HTTPS, например из статьи о редиректе на HTTPS для нескольких доменов и поддоменов, в этом сценарии должна быть отключена или ограничена другим доменом.

Проверка схемы за reverse proxy или балансировщиком

Если TLS завершается на CDN, балансировщике или внешнем reverse proxy, Nginx может получать обычный HTTP-трафик во внутренней сети. Исходная клиентская схема обычно передается в X-Forwarded-Proto или через PROXY protocol.

Передавайте X-Forwarded-Proto только от доверенного прокси. Клиент не должен иметь возможность самостоятельно подменить этот заголовок. Приложение должно знать, какая схема считается целевой: если оно видит https и самостоятельно строит URL на HTTPS, оно может вернуть обратный редирект даже при корректном Nginx-конфиге.

location / {
    proxy_pass http://app_upstream;
    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-Proto http;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}

Если перед Nginx работает внешний балансировщик, проверьте его правила отдельно. Он не должен переписывать HTTP-ответ Nginx обратно на HTTPS или направлять порт 80 в listener с обязательным TLS.

Как проверить цепочку переходов до публикации

Сначала запросите HTTPS-адрес без автоматического перехода:

curl -I https://example.com/path?check=1

Ожидаемый результат: статус 302, 307 или 301 и заголовок Location: http://example.com/path?check=1. Затем проверьте HTTP напрямую:

curl -I http://example.com/path?check=1

HTTP-запрос должен вернуть конечный статус приложения, например 200, 401 или ожидаемый 404, но не новый переход на HTTPS. Для выявления петли выполните:

curl -I -L --max-redirs 5 https://example.com/path?check=1

Если curl исчерпал лимит переходов, проверьте оба виртуальных хоста, правила балансировщика и настройки редиректов самого приложения.

Безопасность, HSTS и поведение браузеров при переходе на HTTP

HTTP передает заголовки, URL, формы и тело запроса без TLS-шифрования. Узел сети между клиентом и сервером может прочитать или изменить такой трафик. Ограничение доступа IP-фильтрами и VPN снижает риск, но не превращает HTTP в безопасный публичный протокол.

Почему HSTS может заблокировать редирект на HTTP

Политика Strict-Transport-Security хранится у клиента. Если домен ранее отправил HSTS с большим max-age, браузер может переписать HTTP-адрес обратно на HTTPS до сетевого запроса. Параметр includeSubDomains распространяет это поведение на поддомены. Домен из HSTS preload-списка также нельзя быстро перевести на HTTP изменением конфигурации Nginx.

Проверяйте downgrade в новом профиле браузера, на отдельном тестовом домене без HSTS или после очистки локальной политики домена. Заголовок Strict-Transport-Security: max-age=0 браузер учитывает только при получении по HTTPS и он не отменяет preload.

Cookie с атрибутом Secure не отправляются по HTTP. После редиректа пользователь может потерять сессию, получить повторный запрос на вход или ошибку CSRF. Обычные cookies, URL-параметры и токены без надлежащей защиты могут быть перехвачены в сети.

  • Проверьте Secure, HttpOnly, SameSite и доменную область cookies.
  • Проверьте вход, выход, сброс пароля, OAuth callback и CSRF-защиту.
  • Исключите передачу API-ключей и bearer-токенов через HTTP.
  • Уберите чувствительные значения из query string до тестирования перехода.

Браузерные политики и смешанный контент

Переход верхнего документа с HTTPS на HTTP по ответу 3xx сам по себе не считается mixed content. После загрузки HTTP-документа возникают другие ограничения: service worker обычно требует secure context, жестко заданные HTTPS-адреса могут вести пользователя обратно на защищенную схему, а CSP с директивой upgrade-insecure-requests переписывает обращения к ресурсам на HTTPS.

Проверьте CSP, JavaScript-конфигурацию API endpoint, iframe, абсолютные ссылки, кэш браузера и service worker. Тестируйте в Chrome, Edge и используемых Chromium-сборках после установки актуальных обновлений. Обновления закрывают известные уязвимости клиентского ПО, но не меняют необходимость проверить фактическую цепочку редиректов.

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

SEO: 301 редирект с HTTPS на HTTP и выбор кода ответа

Для публичного сайта HTTPS должна оставаться канонической схемой. Редирект с HTTPS на HTTP создает риск противоречивых сигналов: поисковый робот видит одно направление в Location, а canonical, sitemap.xml или внутренние ссылки могут указывать на другое. Это способно вызвать дублирование URL и повторную обработку страниц в индексации.

301, 302 или 307: какой код выбрать

КодКогда применятьОсобенность
301Подтвержденный постоянный переходДолго кэшируется браузерами и воспринимается как постоянный сигнал.
302Тест, аварийный обход проблемы, краткая миграцияПодходит для временной браузерной навигации.
307Временный переход для запросов, где критичен методСохраняет HTTP-метод и тело запроса при следовании редиректу.

Не направляйте авторизационные и платежные POST-запросы на HTTP даже через 307. Сохранение метода не устраняет риск передачи тела запроса без шифрования.

Canonical, sitemap.xml и внутренние ссылки

При постоянном переключении все сигналы должны указывать на одну схему. Проверьте canonical, hreflang, sitemap.xml, Open Graph, RSS-ленты, шаблоны ссылок и абсолютные URL в JavaScript. Для временного downgrade не меняйте SEO-метаданные на HTTP: это уменьшит риск закрепить временную техническую схему как постоянную.

Убедитесь, что robots.txt, карта сайта и внутренние ссылки не создают маршрут обратно на HTTPS. Для крупных публичных проектов лучше устранить причину TLS-сбоя и вернуть единый HTTPS-каноникал.

Почему публичный сайт обычно должен остаться на HTTPS

HTTPS защищает соединение, поддерживает Secure-cookie, работает с современными браузерными возможностями и соответствует ожиданиям пользователей. Для базы знаний, документации и публичных страниц отказ от HTTPS добавляет риски без практической выгоды. HTTP оправдан как ограниченное техническое исключение с понятным сроком завершения.

Проверка и диагностика после изменения конфигурации

Проверку выполняют до публикации для каждого домена, поддомена и маршрута, который затрагивает правило. Один успешный запрос к главной странице не подтверждает работу API, callback URL и вложенных путей.

Команды nginx -t и reload

sudo nginx -t
sudo systemctl reload nginx
sudo systemctl status nginx --no-pager

При ошибке синтаксиса проверьте путь к файлу и строку, указанные в выводе nginx -t. При ошибке после reload посмотрите настроенный error_log. В стандартных установках он часто находится в /var/log/nginx/error.log, но точный путь задается в основной конфигурации.

Проверка заголовка Location через curl

curl -I https://example.com/docs/page?utm=test
curl -I http://example.com/docs/page?utm=test
curl -I -L --max-redirs 5 https://example.com/docs/page?utm=test

Проверьте код ответа, заголовок Location, hostname, порт, путь и параметры запроса. Команда без -L показывает первый ответ сервера. Команда с -L выявляет цикл и показывает конечную точку цепочки.

Для проверки GET-запроса вместо HEAD используйте:

curl -sS -D - -o /dev/null https://example.com/docs/page?utm=test

Это полезно, когда приложение отвечает на GET, но обрабатывает HEAD нестандартно.

Критерии успешного переключения и план отката

  • HTTPS возвращает один ожидаемый редирект на HTTP.
  • HTTP отдает конечный ресурс и не переводит пользователя обратно на HTTPS.
  • Путь и query string сохраняются.
  • Нет повторяющихся кодов 301, 302 или 307 в curl-цепочке.
  • Авторизация, API и callback-маршруты проверены отдельно либо исключены из HTTP-схемы.
  • В access log и error log нет неожиданных ошибок, повторных запросов или обращений к неверному virtual host.
  • HSTS, Secure-cookie, CSP и service worker проверены в браузере.

Для отката верните прежнее правило в блоке 443, например редирект HTTP на HTTPS или обычное проксирование в приложение. Затем снова выполните nginx -t, reload и curl-проверки. Если в браузере ранее кэшировался 301, тестируйте в чистом профиле или очистите кеш для домена.

Практический итог: безопасный порядок действий

Сначала подтвердите, что downgrade нужен для теста, внутреннего доступа, короткой миграции или legacy-интеграции. Затем выберите временный код 302 или 307, настройте return в HTTPS-блоке и убедитесь, что порт 80 отдает приложение без обратного перехода. После nginx -t и reload проверьте заголовки через curl, браузерные ограничения, авторизацию и логи.

Минимальный чек-лист перед публикацией

  • Есть резервная копия конфигурации virtual host.
  • Порт 443 возвращает http:// с $request_uri.
  • Порт 80 не содержит безусловного редиректа обратно на HTTPS.
  • Проверены default_server, дублирующиеся server_name и include-файлы.
  • Заголовок X-Forwarded-Proto согласован между балансировщиком, Nginx и приложением.
  • HSTS и preload не блокируют переход на HTTP в целевом браузере.
  • Secure-cookie, сессии, CSP, service worker и API не ломают рабочий сценарий.
  • Location сохраняет hostname, порт, путь и параметры.
  • Для публичного сайта canonical, sitemap.xml и внутренние ссылки не переключены на HTTP без подтвержденной причины.
  • Подготовлен быстрый откат на HTTPS и повторная проверка после него.
Поделиться:
Сохранить гайд? В закладки браузера