Вы настроили редирект с HTTP на HTTPS, но сайт продолжает открываться по HTTP. Или того хуже: браузер перекидывает с HTTPS обратно на HTTP, создавая петлю. Причина почти всегда в конфликте правил, кэше HSTS или ошибке в конфиге сервера. Разберём, как найти источник проблемы и вернуть корректный редирект.
Как должен работать редирект на HTTPS
Правильная схема выглядит так: пользователь открывает http://site.ru, сервер отдаёт 301 на https://site.ru, браузер загружает защищённую версию. Все внутренние ссылки, canonical, sitemap и редиректы должны вести на HTTPS.
Типичная конфигурация для nginx:
server { listen 80; server_name site.ru www.site.ru; return 301 https://site.ru$request_uri; }
Для Apache в .htaccess:
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}/$1 [R=301,L]
Если редирект настроен так, но сайт всё равно открывается по HTTP или возвращает на HTTP — значит, где-то есть конфликтующее правило или кэш.
Причина 1: петля редиректов
Петля возникает, когда одно правило отправляет на HTTPS, а другое — обратно на HTTP. Браузер видит бесконечную цепочку и выдаёт ошибку ERR_TOO_MANY_REDIRECTS.
Типичные сценарии:
— в .htaccess есть правило с HTTP на HTTPS и одновременно правило с HTTPS на HTTP;
— в nginx один server-блок редиректит на HTTPS, а другой — на HTTP;
— CMS или плагин добавляет собственный редирект, конфликтующий с серверным;
— CDN или прокси переписывает протокол в обратную сторону.
Как найти петлю:
— проверьте цепочку редиректов через инструмент проверки;
— посмотрите, сколько переходов происходит до конечной страницы;
— проверьте конфиг nginx и .htaccess на противоречащие правила;
— проверьте настройки CMS и плагинов.
Для диагностики используйте проверка редиректов — инструмент покажет всю цепочку и укажет, где она зацикливается.
Причина 2: кэш HSTS
HSTS (HTTP Strict Transport Security) — заголовок, который заставляет браузер обращаться к сайту только по HTTPS. Если HSTS был включён, а затем вы отключили HTTPS или настроили редирект неправильно, браузер всё равно будет пытаться открыть HTTPS-версию — и может получить ошибку или вернуться на HTTP через промежуточный редирект.
Проблема в том, что HSTS кэшируется браузером на срок, указанный в заголовке max-age. Если max-age был 31536000 (1 год), браузер будет помнить о HSTS год, даже если вы отключили заголовок.
Что делать:
— проверьте, отдаётся ли заголовок Strict-Transport-Security;
— проверьте значение max-age;
— учтите, что сбросить HSTS у пользователей мгновенно невозможно;
— не отключайте HTTPS, если HSTS был включён с большим max-age.
Причина 3: неправильный редирект в CMS
Многие CMS и плагины имеют собственные настройки редиректов. Например, в WordPress настройка «WordPress Address» и «Site Address» может быть указана с HTTP, и тогда CMS будет редиректить на HTTP, конфликтуя с серверным редиректом.
Что проверить:
— адрес сайта в настройках CMS;
— настройки плагинов безопасности и SEO;
— правила в .htaccess, добавленные CMS;
— настройки кэширующих плагинов.
Если CMS настроена на HTTP, а сервер редиректит на HTTPS, возникает конфликт. Нужно привести настройки CMS в соответствие с HTTPS.
Причина 4: CDN или прокси
Если сайт работает через CDN или обратный прокси, возможны несколько проблем:
— CDN отдаёт контент по HTTP, хотя origin работает по HTTPS;
— CDN переписывает протокол в ссылках;
— CDN кэширует HTTP-версию и отдаёт её пользователям;
— прокси не передаёт заголовок X-Forwarded-Proto, и приложение думает, что работает по HTTP.
Что проверить:
— настройки SSL в CDN;
— режим SSL (Flexible, Full, Full Strict);
— передаётся ли заголовок X-Forwarded-Proto;
— кэшируется ли HTTP-версия отдельно.
Режим Flexible часто становится причиной петли: CDN общается с origin по HTTP, origin редиректит на HTTPS, CDN снова обращается по HTTP — и цикл замыкается.
Как исправить редирект
Пошаговый план:
— проверьте цепочку редиректов и найдите петлю;
— уберите противоречащие правила из nginx, .htaccess и CMS;
— оставьте один редирект с HTTP на HTTPS;
— проверьте настройки CMS и приведите их к HTTPS;
— проверьте настройки CDN и переключите режим SSL на Full или Full Strict;
— очистите кэш CDN и кэш CMS;
— проверьте, что SSL-сертификат действителен;
— проверьте результат через инструмент.
Если HSTS был включён с большим max-age, учтите, что браузеры пользователей будут помнить о HSTS до истечения срока. В этом случае HTTPS должен работать корректно — отключать его нельзя.
Как проверить результат
Чек-лист:
— http://site.ru отдаёт 301 на https://site.ru;
— https://site.ru отдаёт 200;
— нет цепочки из более чем одного редиректа;
— нет петли ERR_TOO_MANY_REDIRECTS;
— canonical указывает на HTTPS;
— sitemap содержит HTTPS-URL;
— внутренние ссылки ведут на HTTPS;
— HSTS отдаётся корректно.
Если нужно проверить сразу несколько параметров — редиректы, SSL, HSTS, canonical — логично перейти к SEO-аудиту.
Частые ошибки при настройке HTTPS-редиректа
— противоречащие правила в nginx и .htaccess;
— редирект только для главной, но не для внутренних страниц;
— настройки CMS, указывающие на HTTP;
— режим Flexible в CDN;
— отсутствие заголовка X-Forwarded-Proto;
— HSTS с большим max-age при неработающем HTTPS;
— кэш CDN, отдающий HTTP-версию;
— несколько редиректов подряд вместо одного.
FAQ
Почему после настройки HTTPS сайт возвращает на HTTP?
Скорее всего, есть конфликтующее правило редиректа, настройки CMS указывают на HTTP, или CDN работает в режиме Flexible. Проверьте цепочку редиректов.
Что такое петля редиректов?
Это ситуация, когда одно правило отправляет на HTTPS, а другое — обратно на HTTP. Браузер выдаёт ошибку ERR_TOO_MANY_REDIRECTS.
Как найти петлю редиректов?
Используйте инструмент проверки редиректов. Он покажет всю цепочку и укажет, где она зацикливается.
Может ли HSTS мешать?
Да. Если HSTS был включён с большим max-age, браузер будет помнить о нём долго. Отключать HTTPS в этом случае нельзя.
Что делать, если CMS редиректит на HTTP?
Проверьте настройки адреса сайта в CMS и приведите их к HTTPS. Также проверьте плагины, которые могут добавлять свои редиректы.
Почему CDN возвращает на HTTP?
Возможно, CDN работает в режиме Flexible: он общается с origin по HTTP, origin редиректит на HTTPS, и возникает петля. Переключите режим на Full или Full Strict.
Нужен ли редирект для каждой страницы?
Нет. Достаточно одного правила на уровне сервера, которое применяется ко всем URL. Но проверьте, что правило работает и для внутренних страниц.
Влияет ли неправильный редирект на SEO?
Да. Петля редиректов может привести к тому, что страницы выпадут из индекса, а трафик потеряется.
Как проверить, что редирект работает правильно?
Проверьте, что http отдаёт 301 на https, https отдаёт 200, и нет цепочки из более чем одного перехода.
Что делать, если HSTS уже закэширован у пользователей?
Обеспечить корректную работу HTTPS. Сбросить HSTS у пользователей мгновенно невозможно, но можно уменьшить max-age для будущих посещений.
