Раньше многие считали, что для сайта на сервере достаточно обычного HTTP: мол, если форма работает, значит всё в порядке. На практике открытый канал оставляет трафик читаемым для посторонних, а ошибки в настройке легко ломают ссылки, редиректы и авторизацию.

Какую проблему решаем

Если сайт отвечает по HTTP, браузер и сервер обмениваются данными без шифрования. Это особенно плохо для логинов, паролей, токенов и cookie, а также для любых форм, где пользователь вводит личные данные.

Переход на HTTPS закрывает этот промежуток: данные уходят по шифрованному каналу, а сайт получает нормальный базовый уровень доверия у браузеров и поисковиков. Но одного сертификата мало — важно, чтобы сервер ещё и правильно понимал, по какому протоколу к нему пришёл запрос.

Если вам нужно освежить базу по угрозам на периметре, посмотрите разбор почему firewall не спасает от атак на периметре. Там хорошо видно, почему защита сайта — это не одна галочка в панели хостинга.

Что подготовить

Перед настройкой соберите три вещи: домен, сервер или VPS и рабочий бэкенд, который уже отвечает на локальном порту. В примере из источника это контейнер с приложением, а перед ним — обратный прокси, который принимает внешние запросы.

Понадобится и SSL/TLS-сертификат. Его можно выпустить автоматически через прокси-сервер, если тот умеет работать с доменом и принимать входящие соединения на 443-м порту.

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

Пошаговые действия

1. Поставьте обратный прокси перед сайтом

Схема простая: внешний трафик сначала идёт не в приложение, а в прокси, а уже он передаёт запросы бэкенду. Так вы скрываете внутреннюю архитектуру и можете держать приложение на отдельном порту, не открывая его наружу.

Это удобно и для нескольких сервисов на одном сервере: снаружи они выглядят как один сайт, а внутри работают раздельно.

2. Выпустите сертификат и включите HTTPS

Прокси должен сам получить сертификат для домена и начать принимать запросы по HTTPS. После этого браузер будет общаться с ним по защищённому каналу, а прокси — передавать запросы дальше по внутренней сети.

На этом месте многие считают задачу закрытой, но это не так. Если приложение не знает, что внешний запрос пришёл по HTTPS, оно может продолжить генерировать ссылки со схемой http://.

3. Передайте приложению правильную схему

Нужен заголовок X-Forwarded-Proto. Он сообщает бэкенду, какой протокол использовал клиент на входе: http или https.

Прокси добавляет этот заголовок в запрос, а приложение читает его и корректно строит ссылки, редиректы и адреса для url_for. Без этого браузер нередко уходит в бесконечные перенаправления или ругается на смешанный контент.

4. Обработайте заголовок на стороне приложения

В приложении добавьте middleware — промежуточную функцию, которая смотрит на заголовки каждого запроса. Если она видит X-Forwarded-Proto: https, то меняет схему запроса на https ещё до обработки маршрутов.

Так бэкенд начинает вести себя так, будто общается с клиентом напрямую по защищённому каналу. Это простое решение убирает большую часть ошибок со ссылками и помогает не ломать поведение форм и перенаправлений.

5. Проверьте cookie и локальную разработку

Если сайт использует cookie, ставьте флаг secure=True для боевого окружения. Тогда браузер отправит их только по защищённому каналу.

Для локальной разработки этот флаг обычно отключают, иначе тесты на http://localhost начнут сбоить. Здесь важно разделять боевую конфигурацию и стенд для разработки, чтобы не искать призрачную ошибку в коде.

Если вы работаете с внешними командами или часто подключаетесь из командировок, можно добавить защиту трафика для поездок и удалённой работы как один из слоёв безопасности. Это не заменяет HTTPS на сайте, но помогает снизить риски в чужих сетях.

Как проверить себя

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

После этого проверьте генерацию ссылок в шаблонах и ответах API. Если где-то всё ещё всплывает http://, значит приложение не увидело заголовок прокси или middleware срабатывает не там, где нужно.

Отдельно посмотрите на cookie и авторизацию. Если сессия сбрасывается или не сохраняется, сначала проверьте флаг secure, а потом — настройки домена и пути.

Что делать, если не получилось

Если сайт не открывается по HTTPS, начните с простого: домен должен указывать на нужный сервер, а на 443-м порту должен слушать именно прокси. Затем проверьте логи сервера и выпуск сертификата.

Если HTTPS работает, но приложение продолжает строить ссылки по http://, значит проблема почти всегда в заголовке X-Forwarded-Proto или в middleware. В таких случаях полезно временно упростить конфигурацию и проверить запросы вручную.

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

Практический чек-лист

  • Домен указывает на нужный сервер.
  • Прокси принимает запросы на HTTPS.
  • Сертификат выпущен и подхватывается автоматически.
  • Бэкенд получает заголовок X-Forwarded-Proto.
  • Middleware на стороне приложения читает схему запроса.
  • Внутренние ссылки и редиректы не возвращают http://.
  • Cookie в боевом окружении отмечены как secure.
  • Браузер не показывает предупреждений о соединении.
Поделиться: