Пошагово разберем настройка собственного домена: DNS записи, выпуск SSL, редиректы, куки и план переключения без простоя.
Смена домена выглядит как простая задача: поменяли записи DNS, выпустили сертификат и готово. На практике всплывают детали, которые не видны до переключения. И именно они обычно дают ощущение, что "все работало, а теперь внезапно нет".
Часто ломается не только сайт, но и все вокруг: API, загрузка статических файлов, вебхуки, мобильное приложение, админка. Если фронтенд и сервер живут на разных поддоменах, один неверный CNAME или забытый поддомен вроде api или cdn может оставить часть пользователей с белым экраном или ошибками в запросах.
DNS обновляется не мгновенно. У разных провайдеров и у разных пользователей кэш живет по-разному: кто-то увидит новый сайт через минуту, а кто-то еще час будет ходить на старый адрес. В этот период у вас фактически два мира одновременно, и отсюда появляются "плавающие" баги: у коллеги уже все нормально, а у клиента все еще старая версия.
SSL тоже добавляет неожиданностей. Если сертификат не выдан, выдан не на тот домен или не включает нужные варианты (например, с www), браузер покажет предупреждение или просто не даст нормально войти. А если у вас есть авторизация, смешивание http и https легко приводит к тому, что куки не сохраняются.
Отдельная классика - редиректы и куки. Неправильная цепочка редиректов (http -> https -> www -> без www) может зациклить переходы. А если кука сессии была привязана к старому домену или выставлены строгие параметры SameSite и Secure, пользователь может попасть в бесконечный круг "войти -> обновить -> снова войти".
Чтобы сюрпризов стало меньше, заранее подготовьте базовые вещи:
httpsСамые неприятные проблемы с доменом происходят не из-за DNS, а из-за спешки и разрозненных доступов. Поэтому сначала зафиксируйте, что именно вы переносите и как должен выглядеть финальный адрес.
Определите текущий адрес приложения и целевой домен в одном месте: будет ли это example.ru или www.example.ru. Сразу решите, какой вариант будет основным, а какой - только перенаправлять. Если оставить это на потом, почти гарантированно появятся дубли страниц, странные редиректы и путаница в куках.
Дальше проверьте доступы, пока не начались работы. Нужны логины и права на: аккаунт у регистратора домена, панель управления DNS (иногда это разные места), платформу или хостинг, где крутится приложение, и место, где выпускаются или подключаются SSL-сертификаты. Частая ситуация: домен оформлен на одного человека, DNS у другого, а деплой у третьего.
Соберите список поддоменов, которые реально нужны. Обычно это что-то вроде app, api, admin, static. Лучше заранее вычеркнуть лишнее, чем потом обнаружить, что старый api.old-example.ru был прописан в мобильном приложении или в интеграции.
Перед переключением заранее уменьшите TTL у текущих DNS-записей. Например, за 24-48 часов снизьте TTL до 300-600 секунд, чтобы изменения разошлись быстрее и откат был проще.
И назначьте короткое окно работ и понятный канал статуса для команды: кто меняет DNS, кто проверяет сертификат, кто смотрит логи. Даже простой текстовый план в несколько строк снижает шанс, что вы забудете про редирект с www или проверку авторизации после смены домена.
DNS можно представить как телефонную книгу интернета: по имени домена он находит, куда отправить пользователя. При настройке собственного домена чаще всего вы трогаете всего несколько типов записей, но ошибки в них дают самые неприятные симптомы: сайт то открывается, то нет; сертификат не выпускается; часть людей попадает на старую версию.
A-запись указывает IPv4-адрес сервера, AAAA - то же самое для IPv6. Это удобно, когда у вас один стабильный IP. Риск в том, что при смене хостинга или балансировщика IP часто меняется, и тогда придется обновлять запись и ждать, пока изменения разойдутся. Если у вас нет уверенности, что IP будет жить годами, лучше привязываться не к IP, а к имени.
CNAME делает домен псевдонимом другого домена (например, app.example.ru указывает на имя платформы или CDN). Минус: многие DNS-провайдеры не разрешают CNAME для корня домена (example.ru), потому что там должны быть NS и SOA записи.
Если нужен корневой домен без привязки к IP, ищите у DNS-провайдера ALIAS или ANAME. По смыслу это как CNAME для корня: вы указываете имя, а провайдер сам подставляет актуальные IP.
TXT чаще всего нужен для подтверждения владения доменом и для автоматического выпуска SSL-сертификата (а также для настроек почты, но это отдельная тема). Обычно вы добавляете строку, которую дает сервис, и ждете, пока она начнет находиться в DNS.
TTL - это время жизни записи в кэше. Если TTL высокий, часть пользователей может видеть старый маршрут еще несколько часов.
Полезное правило перед переключением:
Перед тем как трогать записи, решите, какой адрес будет основным: корень (example.ru) или www (www.example.ru). Обычно выбирают один как главный, а второй делают алиасом с редиректом. Так меньше путаницы в ссылках, аналитике и куках.
Дальше зафиксируйте текущее состояние DNS, даже если домен еще "пустой". Сохраните список записей и текущий TTL. Если что-то пойдет не так, понятный "снимок" поможет быстро откатиться.
Практичный порядок действий:
www обычно CNAME на целевой хост.api.example.ru) и создайте для него CNAME или A-запись, чтобы фронтенд и бэкенд не мешали друг другу.После сохранения записей не полагайтесь на проверку только у себя дома. DNS обновляется не одновременно, и часть пользователей может еще видеть старый маршрут.
Проверьте, что записи видны из разных сетей: домашний интернет, мобильная сеть, рабочий Wi-Fi. Если есть возможность, спросите коллегу в другом городе. Минимальный тест: открывается ли сайт по корню и по www, и ведет ли api туда, куда вы ожидаете.
На случай отката заранее решите, что считается "точкой возврата": какие записи вернуть, какой TTL поставить обратно, и сколько времени вы готовы ждать перед решением откатываться.
SSL-сертификат нужен, чтобы браузер открывал сайт по https без предупреждений, а логины, платежи и куки не утекали. При настройке собственного домена чаще всего проблемы начинаются не с самого сертификата, а с проверки домена перед выдачей.
Проверка домена (DCV) подтверждает, что вы управляете доменом. Самые частые варианты:
Wildcard-сертификат (например, *.example.ru) нужен, если вы действительно используете много поддоменов: api, app, admin, cdn. Если у вас только один домен и, максимум, www, wildcard часто лишний: он сложнее в обслуживании, обычно требует DNS-01 и иногда добавляет путаницу при выпуске.
Отдельная причина ошибок, даже когда сертификат выпущен, - цепочка сертификатов. Сервер должен отдавать не только ваш сертификат, но и промежуточные (intermediate). На части устройств все будет выглядеть нормально, а на других появится "неполный SSL" или сайт просто не откроется. Часто это всплывает на старых Android или в корпоративных сетях.
Чтобы не делать все вручную, проверьте автопродление. Если платформа выпускает сертификаты сама (как обычно при хостинге и деплое), убедитесь, что домен не "отвалится" из-за смены DNS или закрытого 80 порта, если используется HTTP-01.
После выпуска сделайте быструю проверку:
https-версию без предупреждений и проверьте замок в адресной строке.www и без www, чтобы понять, где реально работает сертификат.Пример: вы развернули веб-приложение на TakProsto и добавили домен. Если планируете и app, и api на отдельных поддоменах, заранее решите, нужен ли wildcard. Иначе проще выпустить обычный сертификат на корень и www и быстрее пройти проверку.
Редиректы нужны, чтобы у сайта был один "правильный" адрес, а все остальные варианты аккуратно вели туда же. Это важно и для пользователей (меньше странных ошибок), и для поиска (меньше дублей). Для настройки собственного домена сначала выберите канонический вариант: всегда https, и дальше либо с www, либо без него. Главное - один.
После этого настройте принудительный переход с http на https. Самая частая проблема - циклы, когда правило отправляет запрос туда, откуда он снова попадает под редирект. Проверяйте оба направления: http -> https, и www <-> без www. Если вы открываете страницу и видите "слишком много перенаправлений", почти всегда причина в конфликтующих правилах.
Редирект должен сохранять путь и параметры запроса. Иначе ломаются UTM-метки, рекламные кампании, приглашения по реферальным ссылкам, а иногда и важные действия в приложении (например, возврат на нужную страницу после входа). Правильный редирект переводит http://example.ru/pricing?utm_source=ad в https://example.ru/pricing?utm_source=ad, а не на главную.
Код редиректа тоже имеет значение. 301 (постоянный) подходит, когда вы уверены в финальном адресе и правилах. 302 (временный) безопаснее на время миграции: его проще откатить, и поисковые системы обычно не "переучивают" адрес так агрессивно. Частый подход: сначала 302 на 1-2 дня проверки, затем 301.
Если вы переезжаете со старого домена или меняете структуру страниц, продумайте точечные правила для важных URL (лендинги, документация, страницы оплаты). Старайтесь не делать "все на главную" - это раздражает пользователей и ухудшает качество трафика.
Короткая проверка перед запуском:
http/https и www/без www, убедитесь, что все ведут в один адрес.При переносе на новый домен чаще всего ломается не DNS, а вход в аккаунт. Пользователь открывает сайт, логинится, обновляет страницу и снова видит форму входа. Почти всегда причина в куках: браузер больше не отправляет их на нужный хост.
Главная ловушка - атрибут Domain. Если раньше кука была для oldsite.ru, а вы переехали на newsite.ru, старая кука просто не подходит. Еще хуже, когда Domain задан слишком широко или с ошибкой: тогда кука может не установиться вообще.
Для простого случая безопаснее ставить куки без Domain (тогда они привязаны ровно к текущему хосту). Если нужно делиться сессией между app.example.ru и api.example.ru, тогда Domain обычно делают .example.ru, но проверьте, что оба сервиса действительно живут в этом домене.
После перехода на https включайте Secure, иначе современный браузер может вести себя непредсказуемо на смешанных схемах. SameSite тоже важен:
Lax подходит большинству сайтов и защищает от лишних отправок куки.None нужен для внешней авторизации и редиректов между доменами, но тогда обязательно Secure.Если есть вход через внешний провайдер (OAuth), проверьте две вещи: CORS (какие origin разрешены для запросов) и callback URL (куда провайдер возвращает пользователя). При настройке собственного домена эти значения почти всегда нужно обновить, иначе редирект пройдет, но сессия не закрепится.
Перед переключением домена протестируйте руками:
www и без wwwЕсли хотя бы в одном сценарии сессия "слетает", сначала смотрите на Domain, Secure и SameSite в Set-Cookie, и только потом ищите проблему в приложении.
Лучший способ избежать простоя - переключать домен как переключатель света, а не как ремонт с перекрытием входа. Для этого старый и новый домены должны какое-то время жить параллельно, а вы должны заранее подготовить быстрый откат.
За 24-48 часов до переключения уменьшите TTL у записей, которые будете менять. Тогда DNS быстрее подхватит новую цель. В это же окно проверьте, что на новом домене уже работают SSL, редиректы и есть простая страница статуса (хотя бы текст: что делать, если что-то не грузится).
Дальше поднимите новый домен параллельно со старым: тот же фронт, тот же бэкенд, те же переменные окружения. Если вы делаете настройку собственного домена в платформе вроде TakProsto, удобно сначала подключить домен как дополнительный, прогнать тесты и только потом переводить основной трафик.
Перед сменой DNS прогоните короткий набор проверок на новом домене:
https и единый вариант с www или безПереключение делайте в спокойное время, но не ночью, чтобы команда была на связи. После смены DNS старый домен оставьте рабочим: он еще будет открываться у части людей из-за кэша.
Заранее зафиксируйте план отката:
Первые 1-2 часа мониторьте не только "сайт открывается", а действия: логин, отправка форм, платежи, ошибки 4xx/5xx и всплеск обращений в поддержку. Это быстрее ловит проблемы, чем общие метрики.
Большинство проблем с доменом не выглядят как "все упало". Чаще это странные симптомы: у части людей сайт работает, у части нет; кто-то не может войти; редиректы крутятся по кругу. Ниже - ошибки, которые встречаются чаще всего, и способы поймать их до запуска.
Одна из классических ловушек - CNAME на корень домена (example.ru). Многие DNS-провайдеры не поддерживают это для apex-записи, и в итоге домен не резолвится как нужно. Признак: www работает, а без www - нет. Заранее проверьте, поддерживает ли провайдер ALIAS/ANAME, или используйте A-запись на нужный IP.
Еще один тихий источник проблем - IPv6. Если у вас случайно осталась AAAA-запись (или ее добавил провайдер), часть пользователей пойдет по IPv6 и увидит ошибку, даже если IPv4 настроен верно. Быстрая проверка: сравните результаты резолва A и AAAA и убедитесь, что AAAA либо корректна, либо отсутствует.
TTL часто ставят "на всякий случай" большим, а потом удивляются, почему переключение растягивается на часы. Если планируется переезд, за 24-48 часов снизьте TTL до 300-600 секунд, а после стабилизации верните обратно.
С редиректами главная ошибка - петля. Например, платформа уже делает редирект на https, а прокси поверх добавляет свое правило, или www и без www гоняют друг друга. Признак: в браузере ошибка "too many redirects". Поймать это легко в приватном окне: откройте http и https варианты, с www и без, и убедитесь, что каждый приходит в одну финальную версию.
С HSTS аккуратнее: если включить его слишком рано, браузеры "запомнят" https, и откат на старую схему станет мучительным. Включайте HSTS только после того, как убедились, что сертификат стабильно выдается и https работает везде.
Наконец, куки. Если сессии привязаны к старому домену, пользователи могут попасть в бесконечный логин: вошел, обновил страницу, снова разлогинило. До запуска проверьте настройки Domain, SameSite и Secure у cookie и продумайте, как будет жить авторизация при смене домена (особенно если меняется поддомен или добавляется www).
Перед тем как переключать домен на новое веб-приложение, полезно пройтись по короткому списку и убрать самые частые причины простоя: неверные DNS-записи, неготовый SSL и неожиданные редиректы. Лучше сделать это за день, когда есть время спокойно проверить.
example.ru, и www.example.ru).www или без), и убедитесь, что весь трафик уходит на https с 301, без цепочек из 2-3 переходов.После переключения важно проверить не только "открывается ли сайт", но и пользовательские сценарии, где чаще всего ломаются куки и авторизация.
https, а браузер не показывает предупреждений.SameSite/Secure.http-ресурсы, браузер может блокировать их тихо и ломать части интерфейса.Представьте: веб-приложение месяцами жило на временном адресе (например, на домене для тестов), а теперь нужен официальный домен компании. Важно не только "прикрутить DNS", но и сделать так, чтобы пользователи не теряли вход, корзину и привычные ссылки.
Команда решает: основной адрес будет https://www.company.ru, а корень company.ru всегда отправляет на www. Так проще для аналитики, сертификатов и единых куки.
За 1-2 дня до переключения снижают TTL у текущих DNS-записей (например, до 300 секунд). В день переезда добавляют записи для нового домена: A или CNAME на ваш хостинг, плюс нужные TXT, если провайдер просит подтверждение. Дальше ждут, пока платформа выпустит SSL-сертификат на company.ru и www.company.ru. Только после этого включают принудительный https и 301-редиректы: с http на https, и с корня на www.
Чтобы убедиться, что ничего не сломалось, делают короткую проверку:
www и без) и смотрят, что всегда открывается https://www...Если часть пользователей все еще видит старую версию (из-за кэша DNS или прокси), план отката простой: временно отключают редиректы и возвращают старые DNS-записи, пока разбираются. Параллельно проверяют настройки куки: домен должен соответствовать company.ru, а не старому временному адресу, иначе сессии "исчезают" после переезда.
После того как вы переключили трафик и убедились, что сайт открывается по новому адресу, работа не заканчивается. Самое ценное сейчас - зафиксировать все, что вы настроили, чтобы через месяц это можно было быстро повторить или проверить, даже если этим займется другой человек.
Соберите в одном месте краткую "карту домена": какие DNS-записи стоят, какие редиректы включены (www и https), где выпускается сертификат, какие заголовки и правила прокси вы меняли. Для команды это часто важнее, чем сама настройка собственного домена, потому что снижает риск случайно сломать рабочую схему.
Проблемы часто всплывают не на главной странице, а в интеграциях, где домен "зашит" в настройках. Пройдитесь по самым частым точкам:
Отдельно заведите привычку раз в неделю или месяц смотреть срок действия SSL. Если сертификат автообновляется, все равно полезно иметь напоминание и простой способ быстро проверить, что цепочка сертификатов отдается корректно.
Перед крупными правками (новые редиректы, смена CDN, правки заголовков) делайте снимок конфигурации. Если вы собираете приложение на TakProsto, заранее подключайте домен через платформу и пользуйтесь снимками и откатом: так проще вернуться к рабочему состоянию за минуты, а не вспоминать, что именно меняли на сервере и в панели домена.
Если нужен быстрый ориентир, где хранить все решения по домену, сертификатам и откату, удобно вести одну короткую страницу в рабочей документации. А в проектах на takprosto.ai этот же подход хорошо сочетается с "планированием" и снапшотами: меньше ручных действий в последний момент и меньше шансов забыть мелочь, которая сломает логин или редиректы.
Начните со списка всех используемых хостов: основной домен, www, api, admin, static/cdn, а также любые «временные» адреса, которые могли попасть в мобильное приложение, вебхуки или настройки OAuth. Затем решите один канонический адрес (обычно https и либо с www, либо без).
Практичный шаг: за 24–48 часов снизьте TTL до 300–600 секунд, чтобы переключение и откат были быстрыми.
Потому что DNS кэшируется на разных уровнях (провайдер, роутер, устройство, корпоративный прокси) и обновляется не одновременно. В итоге часть пользователей ходит на новый адрес, а часть — на старый, и вы видите «плавающие» баги.
Что делать: заранее уменьшите TTL, держите старый домен рабочим во время миграции и проверяйте доступность из разных сетей (дом, мобильный интернет, офис).
Нормальный порядок такой:
Если платформа просит подтверждение домена, чаще всего добавляется TXT-запись. В TakProsto это обычно нужно перед выпуском сертификата и подключением домена.
Для app.example.ru обычно удобен CNAME на имя, которое дает платформа/хостинг (так легче переживать смены IP). Для корня example.ru CNAME часто нельзя, поэтому используйте A-запись на IP или ALIAS/ANAME, если ваш DNS-провайдер поддерживает.
Если видите симптом «www работает, а без www — нет», это часто как раз история про CNAME на корень или неправильную apex-настройку.
Коротко: чаще всего достаточно сертификата на example.ru и www.example.ru. Wildcard (*.example.ru) имеет смысл, если вы реально используете много поддоменов и хотите закрыть их одним сертификатом.
Минусы wildcard: чаще требует DNS-01 (TXT в DNS), сложнее выпуск/поддержка и легко «перекрыть» лишнее, если у вас разные сервисы на поддоменах.
Проверьте три вещи:
www, и без www, если нужно);Симптом «у одних открывается, у других — нет» часто связан с неполной цепочкой или разными маршрутами из‑за DNS-кэша.
Сделайте один канонический адрес и ведите на него все варианты:
http → httpswww ↔ без www (в одну сторону)Редирект должен сохранять путь и параметры запроса, иначе ломаются UTM-метки, приглашения и возврат на нужную страницу после логина. Для миграции можно начать с 302 на 1–2 дня, а потом заменить на 301.
Самая частая причина — cookie больше не подходит новому домену или блокируется политиками браузера.
Проверьте в Set-Cookie:
Подготовьте быстрые проверки до переключения:
http/https и www/без www;И обязательно держите план отката: какие записи вернуть и какой TTL восстановить.
Оставьте старый домен рабочим минимум на время, пока кэши DNS у пользователей не обновятся. В первые 1–2 часа смотрите не только «страница открылась», а реальные действия:
Если вы хостите проект на TakProsto, полезно сделать снапшот перед изменениями и держать готовый откат — это экономит время, если всплывет проблема с редиректами или cookies.
Domain (не привязан ли к старому домену; для простого случая можно вообще не задавать Domain);Secure (обязателен на https);SameSite (обычно Lax; None — только если нужно, и тогда обязательно Secure).Если фронтенд и API на разных поддоменах, отдельно проверьте CORS и что запросы идут на правильный api.-хост.