Как перенаправить HTTP на HTTPS

2026-05-07

redirecthttpsnginxapachehtaccess

После установки SSL-сертификата необходимо перенаправить весь HTTP-трафик на HTTPS. Без перенаправления посетители, заходящие на http://yourdomain.com, не будут использовать зашифрованное соединение — даже если HTTPS доступен.

Используйте перенаправление 301 (постоянное), чтобы поисковые системы перенесли все сигналы ранжирования на HTTPS-адрес.

Nginx

Добавьте отдельный блок server для порта 80, который перенаправляет всё:

server {
    listen 80;
    listen [::]:80;
    server_name example.com www.example.com;
    return 301 https://$host$request_uri;
}

Это сохраняет полный путь URL: http://example.com/page?q=1 → https://example.com/page?q=1.

После редактирования проверьте и перезагрузите:

sudo nginx -t && sudo systemctl reload nginx

Apache

Вариант 1: Перенаправление через VirtualHost (рекомендуется)

Добавьте в конфигурацию Apache:

<VirtualHost *:80>
    ServerName example.com
    ServerAlias www.example.com
    Redirect permanent / https://example.com/
</VirtualHost>

Вариант 2: .htaccess (виртуальный хостинг)

Если у вас нет доступа к конфигурации VirtualHost (виртуальный хостинг), добавьте в .htaccess вашего сайта:

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

Требуется включённый mod_rewrite.

После изменений:

sudo apachectl configtest && sudo systemctl reload apache2

Проверка перенаправления

# Should return 301 with Location: https://...
curl -I http://yourdomain.com

Ожидаемый вывод:

HTTP/1.1 301 Moved Permanently
Location: https://yourdomain.com/

HSTS: двойная защита

После подтверждения работы перенаправления добавьте HSTS (HTTP Strict Transport Security). Это указывает браузерам всегда использовать HTTPS, даже если пользователь вводит http://:

Nginx:

add_header Strict-Transport-Security "max-age=63072000; includeSubDomains" always;

Apache:

Header always set Strict-Transport-Security "max-age=63072000; includeSubDomains"

Начните с небольшого max-age (например, 300 секунд) для тестирования, затем увеличьте до 2 лет (63072000), когда убедитесь, что всё работает.

Предупреждение: После активации HSTS с большим max-age браузеры будут отказываться подключаться по HTTP, даже если вы удалите HTTPS. Убедитесь, что ваша настройка HTTPS стабильна, прежде чем устанавливать большой срок.

Распространённые паттерны перенаправлений

Перенаправление www на без-www + HTTPS

# Nginx: www → non-www, HTTP + HTTPS → HTTPS
server {
    listen 80;
    listen 443 ssl;
    server_name www.example.com;
    ssl_certificate     /etc/ssl/fullchain.pem;
    ssl_certificate_key /etc/ssl/privkey.pem;
    return 301 https://example.com$request_uri;
}

Перенаправление без-www на www + HTTPS

server {
    listen 80;
    listen 443 ssl;
    server_name example.com;
    ssl_certificate     /etc/ssl/fullchain.pem;
    ssl_certificate_key /etc/ssl/privkey.pem;
    return 301 https://www.example.com$request_uri;
}

Перенаправление всего старого домена

server {
    listen 80;
    listen 443 ssl;
    server_name olddomain.com www.olddomain.com;
    ssl_certificate     /etc/ssl/old-fullchain.pem;
    ssl_certificate_key /etc/ssl/old-privkey.pem;
    return 301 https://newdomain.com$request_uri;
}

Для старого домена тоже нужен действительный SSL-сертификат — браузеры должны установить HTTPS-соединение, прежде чем смогут получить перенаправление. Используйте SAN-сертификат, покрывающий оба домена, или отдельный сертификат для старого домена.

Устранение неполадок

Цикл перенаправлений (ERR_TOO_MANY_REDIRECTS)

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

Другая причина: балансировщик нагрузки или прокси (Cloudflare, AWS ALB) завершает SSL и перенаправляет HTTP на ваш сервер. Ваш сервер видит HTTP и перенаправляет. Исправление — проверка заголовка X-Forwarded-Proto:

# Behind a proxy/load balancer
if ($http_x_forwarded_proto = "http") {
    return 301 https://$host$request_uri;
}

Старые HTTP-адреса закешированы в поисковых системах

После настройки перенаправлений сообщите Google об изменении:

Обновите <link rel="canonical"> на https://
Обновите URL-адреса в карте сайта на https://
В Google Search Console добавьте HTTPS-ресурс

Google постепенно обновит проиндексированные URL, следуя перенаправлениям 301.

Часто задаваемые вопросы

Нужно ли перенаправлять www на без-www (или наоборот) одновременно?

Да. Выберите одну каноническую форму и перенаправьте другую. Это позволяет избежать дублирования контента в поисковых системах:

# Redirect www to non-www (Nginx)
server {
    listen 80;
    listen 443 ssl;
    server_name www.example.com;
    return 301 https://example.com$request_uri;
}

Повлияет ли перенаправление на SEO?

Перенаправление 301 передаёт сигналы ранжирования на целевой URL. Google рекомендует перенаправления 301 для миграции с HTTP на HTTPS. Возможны небольшие временные колебания, но в долгосрочной перспективе SEO улучшается благодаря сигналу ранжирования HTTPS.

Как насчёт смешанного контента после перенаправления?

Перенаправление обрабатывает URL-адреса страниц, но если ваш HTML ссылается на ресурсы (изображения, скрипты, CSS) с URL-адресами http://, браузеры заблокируют их или покажут предупреждения. Смотрите наше руководство по исправлению смешанного контента.

Как проверить, правильно ли работает перенаправление?

# Check redirect chain
curl -ILs http://yourdomain.com | grep -E '^HTTP|^Location'