Классическая история: настроили переадресацию со старого домена на новый, проверили — работает. Через неделю выясняется, что трафик упал в разы. Причина почти всегда одна: редирект работает только по http://, а по https:// браузер показывает ошибку безопасности. И поскольку современные браузеры по умолчанию пробуют HTTPS первым, большинство посетителей даже не доходит до перенаправления.
Проблема не в DNS и не в правиле редиректа. Проблема в порядке, в котором браузер устанавливает защищённое соединение.
В чём суть проблемы
Редирект — это инструкция в HTTP-ответе сервера. Чтобы браузер её увидел, нужно сначала получить этот ответ. А чтобы получить ответ по HTTPS, нужно пройти TLS-рукопожатие и проверить SSL-сертификат.
Если сертификата нет или он выдан не на тот домен — соединение обрывается на этапе рукопожатия. Сервер физически не успевает сказать браузеру «иди на новый адрес», потому что браузер не готов его слушать.
Для пользователя это выглядит как страница с красным замочком и предложением «вернуться к безопасности». Подавляющее большинство закрывает вкладку.
Порядок TLS-рукопожатия
Когда пользователь набирает https://staryy-domen.ru, события идут строго в этой последовательности:
- DNS-запрос. Браузер узнаёт IP-адрес сервера по имени домена.
- TCP-соединение. Устанавливается канал связи до сервера.
- TLS-рукопожатие. Стороны договариваются об алгоритмах шифрования.
- Проверка сертификата. Сервер присылает SSL-сертификат, браузер проверяет его подпись, срок действия и соответствие имени домена.
- HTTP-запрос и ответ. Только теперь браузер отправляет
GET /и получает ответ — в котором и содержится редирект.
Шаг 5 выполняется, только если шаг 4 прошёл успешно. Любая проблема с сертификатом — и до HTTP-ответа дело не доходит. Это ключевой момент: редирект живёт на уровне HTTP, а падение происходит на уровне TLS, этажом ниже.
Три причины провала
Сертификата нет вовсе. Сервер, на который указывает DNS-запись, принимает соединения, но HTTPS не обслуживает. Браузер получает отказ на этапе рукопожатия. Ошибка: ERR_SSL_PROTOCOL_ERROR или «Не удалось установить защищённое соединение».
Сертификат есть, но имя не совпадает. Сервер предъявляет валидный сертификат, но выданный на другой домен — например, на novyy-domen.ru, тогда как пользователь пришёл по staryy-domen.ru. Для браузера это признак возможной подмены: кто-то выдаёт себя за ваш сайт. Ошибка: ERR_CERT_COMMON_NAME_INVALID или «Сертификат не соответствует домену».
Сертификат просрочен. Редирект работал год, потом владелец забыл продлить сертификат, и всё встало. Сертификаты Let’s Encrypt живут 90 дней — без автообновления это мина замедленного действия.
Отдельно стоит упомянуть редирект через JavaScript или meta-refresh — его иногда предлагают как «простое решение». Он не работает по той же причине: чтобы выполнить JS или прочитать <meta>, браузеру нужно сначала загрузить HTML-страницу. А страница не загружается без валидного сертификата. Круг замыкается.
Почему у регистраторов не работает
Стандартная услуга «переадресация домена» у большинства российских и зарубежных регистраторов реализована самым дешёвым способом: поднят веб-сервер, который слушает 80-й порт и отвечает HTTP-редиректом. Всё.
| Запрос пользователя | Что делает сервер регистратора |
|---|---|
http://staryy-domen.ru | Отвечает 301, браузер переходит ✅ |
https://staryy-domen.ru | Закрывает соединение, браузер показывает ошибку ❌ |
https://www.staryy-domen.ru | То же самое ❌ |
Причина простая: выпуск и автоматическое продление SSL-сертификата на каждый переадресуемый домен — это инфраструктурная задача, которую регистратор не готов решать в рамках бесплатной или копеечной услуги. Проще закрыть глаза на HTTPS и надеяться, что клиент не заметит.
Клиент замечает через месяц, когда видит в аналитике провал. А потом ещё полгода разбирается, почему позиции в поисковике не переехали — потому что поисковый робот тоже стучится по HTTPS и тоже упирается в ту же ошибку.
Как DNS-сервисы переадресации решают проблему
Правильная архитектура ставит сертификат в центр услуги. Выглядит это так:
- Пользователь направляет DNS-записи домена на серверы сервиса.
- Сервис сразу запрашивает выпуск сертификата через Let’s Encrypt (или аналогичный удостоверяющий центр).
- Проверка владения доменом проходит автоматически — сервис видит, что DNS указывает на него.
- Сертификат устанавливается на серверы сервиса, TLS-рукопожатие с любым пользователем проходит успешно.
- Редирект срабатывает штатным HTTP-ответом с кодом 301 или 302.
Дальше сервис продлевает сертификат сам — обычно за несколько дней до истечения 90-дневного срока. Владелец домена не делает ничего.
В redirekto.ru это работает именно так: после направления DNS-записей на наши серверы сертификат появляется в течение нескольких минут, и редирект начинает отвечать по HTTPS для apex-домена, www-варианта и любых поддоменов без дополнительной настройки.
Альтернативы и их компромиссы
| Способ | HTTPS | Сертификат | Риск в РФ |
|---|---|---|---|
| Переадресация регистратора | ❌ | — | 🟢 нет |
| Свой сервер + Let’s Encrypt | ✅ | Вручную каждые 90 дней | Зависит от хостинга |
| Cloudflare | ✅ | Авто | 🔴 блокировки по соседним IP |
| DNS-сервис переадресации | ✅ | Авто | 🟢 низкий |
Cloudflare технически решает проблему сертификата, но добавляет другую: общие IP-адреса сервиса периодически попадают под блокировки РКН, и ваш домен становится недоступен без какой-либо вины с вашей стороны. Проверить, не затронут ли ваш адрес: тестер РКН.
Как диагностировать проблему
Порядок проверок — от простого к сложному.
Шаг 1. Проверить HTTP отдельно от HTTPS. Если http://staryy-domen.ru редиректит, а https://staryy-domen.ru нет — это классическая проблема с сертификатом, а не с правилом редиректа. Сравнение двух запросов сразу отсекает половину гипотез.
Шаг 2. Проверить DNS-записи. Убедитесь, что домен действительно указывает туда, где настроен редирект:
dig staryy-domen.ru A +short
dig www.staryy-domen.ru A +shortИли визуально, с проверкой по регионам: инструмент dig. Частая ошибка — настроили apex, забыли www.
Шаг 3. Проверить сам сертификат. Посмотреть, что именно отдаёт сервер:
openssl s_client -connect staryy-domen.ru:443 -servername staryy-domen.ru < /dev/nullВ выводе видно: есть ли сертификат вообще, на какой домен он выпущен, когда истекает. Если строка subject= содержит чужое имя — это и есть причина.
Шаг 4. Проверить редирект целиком. Одной командой — по HTTP, HTTPS и с www, и без — удобнее через тестер редиректов. Он показывает цепочку ответов и код на каждом шаге.
Чек-лист правильной настройки
- DNS-записи указывают на сервис, который умеет выпускать сертификаты автоматически — не на «переадресацию регистратора».
- Настроен apex-домен и
www-вариант. Это два разных правила и, часто, два разных сертификата. - Сертификат выпущен именно на тот домен, по которому приходят пользователи, — а не на целевой домен переадресации.
- Редирект работает и по
http://, и поhttps://, и для обеих форм с www/без www. Это четыре точки входа, все должны вести на итоговый URL. - Автопродление сертификата включено. Если это ваш собственный сервер — в расписание добавлено обновление Let’s Encrypt (обычно через
certbot renewв cron). - Код редиректа соответствует задаче: 301 для постоянного переезда, 302 для временного. Разницу и последствия разбираем в отдельной статье.
HTTPS-редирект, который работает одинаково для всех посетителей, — это не удача и не магия. Это следствие того, что сертификат был готов ещё до того, как первый пользователь ввёл адрес в браузер. Всё остальное — вопрос инфраструктуры, которая за это отвечает.