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

После настройки вы получите постоянный редирект с http://example.com на https://example.com, а HTTPS-сайт продолжит обслуживать запросы на 443-м порту. На саму правку конфигурации уйдёт около 15 минут, но до начала у вас уже должны быть DNS-записи и действующий TLS-сертификат.

Что нужно подготовить

• Сервер с установленным Nginx 1.24–1.26. Синтаксис этой настройки стабилен и подходит для этих версий.
• Домен, который указывает на IP сервера через записи DNS.
• Открытые входящие порты 80 и 443 в настройках облака, хостинга или firewall.
• Действующий сертификат для домена и закрытый ключ. В примере используются пути /etc/letsencrypt/live/example.com/fullchain.pem и /etc/letsencrypt/live/example.com/privkey.pem.
• Доступ с правами, позволяющими изменять конфигурацию Nginx.

TLS-сертификат — файл, который подтверждает домен и позволяет браузеру установить зашифрованное HTTPS-соединение. Сам редирект сертификат не создаёт: если HTTPS не настроен, перенаправление приведёт посетителя на неработающий адрес.

HTTP нужно не «выключать», а оставить на 80-м порту только для одного действия: быстро отправлять посетителя на HTTPS.

Шаг 1. Найдите конфигурацию сайта

Конфигурация может находиться в /etc/nginx/sites-available/, /etc/nginx/conf.d/ или в другом каталоге, который подключён из основного файла Nginx. Не редактируйте файл наугад: сначала найдите активную конфигурацию командой:

sudo nginx -T

Команда выводит итоговую конфигурацию вместе с подключёнными файлами. Найдите в выводе строки server_name и имя нужного домена. Проверка шага: вы понимаете, какой именно server-блок отвечает за example.com, а не за соседний сайт.

Шаг 2. Добавьте HTTP-блок с редиректом

В блоке для 80-го порта не размещайте копию сайта. Его задача — вернуть ответ 301 с тем же URI, но с HTTPS и тем же доменом.

server {
    listen 80;
    listen [::]:80;

    server_name example.com www.example.com;

    return 301 https://$host$request_uri;
}

Переменная $request_uri сохраняет путь и query-параметры. Например, запрос http://example.com/catalog?sort=price перейдёт на https://example.com/catalog?sort=price. Проверка шага: после сохранения в итоговой конфигурации есть отдельный server-блок с listen 80 и директивой return 301.

Шаг 3. Настройте HTTPS-блок

Если сайт отдаёт статические файлы, минимальный HTTPS-блок может выглядеть так:

server {
    listen 443 ssl;
    listen [::]:443 ssl;

    server_name example.com www.example.com;

    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

    root /var/www/example.com;
    index index.html;

    location / {
        try_files $uri $uri/ =404;
    }
}

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

Шаг 4. Проверьте конфигурацию и примените её

Сначала проверьте синтаксис, затем перечитайте конфигурацию без полной остановки Nginx:

sudo nginx -t
sudo systemctl reload nginx

Ожидаемый результат первой команды — сообщения syntax is ok и test is successful. После reload проверьте оба направления:

curl -I http://example.com/test?source=check
curl -I https://example.com/test?source=check

Для HTTP ожидайте строку HTTP/1.1 301 Moved Permanently и заголовок Location: https://example.com/test?source=check. Для HTTPS должен прийти ответ сайта, например 200 OK или другой ожидаемый код приложения. Это проверка шага: путь и параметры сохранились, а HTTPS отвечает без ошибки сертификата.

Шаг 5. Проверьте браузер и сторонние ссылки

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

Если сайт работает через CMS, замените базовый адрес сайта на HTTPS в её настройках. Иначе CMS может продолжать генерировать старые HTTP-ссылки, хотя серверный редирект уже настроен. Проверка шага: HTML, CSS, JavaScript, изображения и шрифты загружаются по HTTPS, без предупреждения о смешанном содержимом.

Если не получилось

«nginx: [emerg] cannot load certificate»

Nginx не нашёл сертификат или не может прочитать файл. Проверьте существование путей командой sudo ls -l /etc/letsencrypt/live/example.com/, права доступа и соответствие имени домена. Не указывайте путь к файлу, которого нет: Nginx не запустит новую конфигурацию.

«nginx: [emerg] duplicate listen options»

Для одного адреса и порта уже существует другой HTTPS-блок с конфликтующими параметрами. Через sudo nginx -T найдите все строки listen 443 и уберите дублирующий или старый блок. Оставьте один понятный блок для каждой пары доменов и порта.

HTTP открывается, но редиректа нет

Запрос может попадать в другой server-блок, например в конфигурацию по умолчанию. Проверьте точное написание server_name, наличие DNS-записи и результат curl -I с доменом, а не с IP-адресом. Если перед Nginx стоит CDN или балансировщик, убедитесь, что запрос действительно доходит до этого сервера.

После редиректа появляется бесконечный цикл

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

Браузер сообщает о mixed content

Основной документ уже открыт по HTTPS, но его ресурсы всё ещё указаны как http://. Исправьте абсолютные ссылки в шаблонах, настройках CMS, CSS и JavaScript; редирект ресурсов не всегда устраняет предупреждение и добавляет задержку. После правки очистите кеш CMS и проверьте список заблокированных запросов в DevTools.

Что проверить после настройки

Не удаляйте HTTP-блок сразу после успешного теста. Старые закладки, поисковые ссылки и внешние переходы ещё будут приходить на 80-й порт, и именно он должен отвечать редиректом. Отдельно проверьте автоматическое продление сертификата: после обновления снова выполните sudo nginx -t и тестовый HTTPS-запрос.

Следующий практический шаг — пройти сайт сканером смешанного содержимого и посмотреть access-логи Nginx. Ищите запросы к HTTP-ресурсам, ошибки 404 и неожиданные 301-цепочки. Цепочка из нескольких редиректов замедляет загрузку, а иногда ломает авторизацию и обработку POST-запросов.