Настройка собственного домена для веб-приложения без простоя

Почему настройка домена часто проходит с сюрпризами

Смена домена выглядит как простая задача: поменяли записи DNS, выпустили сертификат и готово. На практике всплывают детали, которые не видны до переключения. И именно они обычно дают ощущение, что "все работало, а теперь внезапно нет".

Часто ломается не только сайт, но и все вокруг: API, загрузка статических файлов, вебхуки, мобильное приложение, админка. Если фронтенд и сервер живут на разных поддоменах, один неверный CNAME или забытый поддомен вроде api или cdn может оставить часть пользователей с белым экраном или ошибками в запросах.

DNS обновляется не мгновенно. У разных провайдеров и у разных пользователей кэш живет по-разному: кто-то увидит новый сайт через минуту, а кто-то еще час будет ходить на старый адрес. В этот период у вас фактически два мира одновременно, и отсюда появляются "плавающие" баги: у коллеги уже все нормально, а у клиента все еще старая версия.

SSL тоже добавляет неожиданностей. Если сертификат не выдан, выдан не на тот домен или не включает нужные варианты (например, с www), браузер покажет предупреждение или просто не даст нормально войти. А если у вас есть авторизация, смешивание http и https легко приводит к тому, что куки не сохраняются.

Отдельная классика - редиректы и куки. Неправильная цепочка редиректов (http -> https -> www -> без www) может зациклить переходы. А если кука сессии была привязана к старому домену или выставлены строгие параметры SameSite и Secure, пользователь может попасть в бесконечный круг "войти -> обновить -> снова войти".

Чтобы сюрпризов стало меньше, заранее подготовьте базовые вещи:

• соберите список всех доменов и поддоменов, которые реально используются
• проверьте, где выпускается SSL и на какие имена он должен быть
• продумайте схему редиректов (один канонический адрес)
• проверьте настройки cookies для нового домена и https
• снизьте TTL в DNS перед переключением, чтобы изменения расходились быстрее

Что подготовить заранее, чтобы не спешить в последний момент

Самые неприятные проблемы с доменом происходят не из-за 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, CNAME, TXT, TTL

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

A и AAAA

A-запись указывает IPv4-адрес сервера, AAAA - то же самое для IPv6. Это удобно, когда у вас один стабильный IP. Риск в том, что при смене хостинга или балансировщика IP часто меняется, и тогда придется обновлять запись и ждать, пока изменения разойдутся. Если у вас нет уверенности, что IP будет жить годами, лучше привязываться не к IP, а к имени.

CNAME, ALIAS/ANAME и корень домена

CNAME делает домен псевдонимом другого домена (например, app.example.ru указывает на имя платформы или CDN). Минус: многие DNS-провайдеры не разрешают CNAME для корня домена (example.ru), потому что там должны быть NS и SOA записи.

Если нужен корневой домен без привязки к IP, ищите у DNS-провайдера ALIAS или ANAME. По смыслу это как CNAME для корня: вы указываете имя, а провайдер сам подставляет актуальные IP.

TXT и TTL

TXT чаще всего нужен для подтверждения владения доменом и для автоматического выпуска SSL-сертификата (а также для настроек почты, но это отдельная тема). Обычно вы добавляете строку, которую дает сервис, и ждете, пока она начнет находиться в DNS.

TTL - это время жизни записи в кэше. Если TTL высокий, часть пользователей может видеть старый маршрут еще несколько часов.

Полезное правило перед переключением:

• за 24-48 часов снизьте TTL до 60-300 секунд
• внесите изменения
• после стабилизации верните TTL повыше, чтобы уменьшить нагрузку на DNS

Шаги настройки DNS для нового домена

Перед тем как трогать записи, решите, какой адрес будет основным: корень (example.ru) или www (www.example.ru). Обычно выбирают один как главный, а второй делают алиасом с редиректом. Так меньше путаницы в ссылках, аналитике и куках.

Дальше зафиксируйте текущее состояние DNS, даже если домен еще "пустой". Сохраните список записей и текущий TTL. Если что-то пойдет не так, понятный "снимок" поможет быстро откатиться.

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

• Снизьте TTL у существующих записей (например, до 300-600 секунд) за несколько часов или за день до переключения.
• Создайте записи для выбранной схемы: для корня обычно A или ALIAS/ANAME (если поддерживается у провайдера), для www обычно CNAME на целевой хост.
• Если у приложения есть API, выделите поддомен (например, api.example.ru) и создайте для него CNAME или A-запись, чтобы фронтенд и бэкенд не мешали друг другу.
• Добавьте TXT-запись для верификации домена, если платформа ее требует (в TakProsto это часто нужно, чтобы подтвердить владение доменом перед выпуском сертификата).
• Оставьте старые записи нетронутыми, пока не убедитесь, что новые начали резолвиться везде.

После сохранения записей не полагайтесь на проверку только у себя дома. DNS обновляется не одновременно, и часть пользователей может еще видеть старый маршрут.

Проверьте, что записи видны из разных сетей: домашний интернет, мобильная сеть, рабочий Wi-Fi. Если есть возможность, спросите коллегу в другом городе. Минимальный тест: открывается ли сайт по корню и по www, и ведет ли api туда, куда вы ожидаете.

На случай отката заранее решите, что считается "точкой возврата": какие записи вернуть, какой TTL поставить обратно, и сколько времени вы готовы ждать перед решением откатываться.

Выпуск SSL и как избежать ошибок с сертификатом

SSL-сертификат нужен, чтобы браузер открывал сайт по https без предупреждений, а логины, платежи и куки не утекали. При настройке собственного домена чаще всего проблемы начинаются не с самого сертификата, а с проверки домена перед выдачей.

Проверка домена (DCV) подтверждает, что вы управляете доменом. Самые частые варианты:

• HTTP-01: центр сертификации просит разместить специальный файл по адресу на вашем домене. Это удобно, когда домен уже указывает на ваш сервер.
• DNS-01: нужно добавить TXT-запись в DNS. Это надежнее, когда сайт еще не переключили, или когда нужен wildcard.

Wildcard-сертификат (например, *.example.ru) нужен, если вы действительно используете много поддоменов: api, app, admin, cdn. Если у вас только один домен и, максимум, www, wildcard часто лишний: он сложнее в обслуживании, обычно требует DNS-01 и иногда добавляет путаницу при выпуске.

Отдельная причина ошибок, даже когда сертификат выпущен, - цепочка сертификатов. Сервер должен отдавать не только ваш сертификат, но и промежуточные (intermediate). На части устройств все будет выглядеть нормально, а на других появится "неполный SSL" или сайт просто не откроется. Часто это всплывает на старых Android или в корпоративных сетях.

Чтобы не делать все вручную, проверьте автопродление. Если платформа выпускает сертификаты сама (как обычно при хостинге и деплое), убедитесь, что домен не "отвалится" из-за смены DNS или закрытого 80 порта, если используется HTTP-01.

После выпуска сделайте быструю проверку:

• Откройте https-версию без предупреждений и проверьте замок в адресной строке.
• Попробуйте с www и без www, чтобы понять, где реально работает сертификат.
• Проверьте на мобильном интернете (не только по Wi-Fi).
• Посмотрите дату окончания и имя домена в деталях сертификата.

Пример: вы развернули веб-приложение на TakProsto и добавили домен. Если планируете и app, и api на отдельных поддоменах, заранее решите, нужен ли wildcard. Иначе проще выпустить обычный сертификат на корень и www и быстрее пройти проверку.

Редиректы: www, https и сохранение ссылок

Редиректы нужны, чтобы у сайта был один "правильный" адрес, а все остальные варианты аккуратно вели туда же. Это важно и для пользователей (меньше странных ошибок), и для поиска (меньше дублей). Для настройки собственного домена сначала выберите канонический вариант: всегда 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 (лендинги, документация, страницы оплаты). Старайтесь не делать "все на главную" - это раздражает пользователей и ухудшает качество трафика.

Короткая проверка перед запуском:

• Откройте 4 варианта: http/https и www/без www, убедитесь, что все ведут в один адрес.
• Проверьте, что редирект сохраняет путь и параметры.
• Убедитесь, что нет цепочек из 3-4 редиректов подряд.
• Прогоните несколько ключевых старых ссылок и зафиксируйте, куда они попадают.
• Проверьте редирект в приватном окне, чтобы кэш браузера не скрывал проблему.

Куки и авторизация: как не потерять сессии пользователей

При переносе на новый домен чаще всего ломается не 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
• запросы к API (особенно если API на другом поддомене)

Если хотя бы в одном сценарии сессия "слетает", сначала смотрите на Domain, Secure и SameSite в Set-Cookie, и только потом ищите проблему в приложении.

План переключения с минимальным риском и без простоя

Лучший способ избежать простоя - переключать домен как переключатель света, а не как ремонт с перекрытием входа. Для этого старый и новый домены должны какое-то время жить параллельно, а вы должны заранее подготовить быстрый откат.

За 24-48 часов до переключения уменьшите TTL у записей, которые будете менять. Тогда DNS быстрее подхватит новую цель. В это же окно проверьте, что на новом домене уже работают SSL, редиректы и есть простая страница статуса (хотя бы текст: что делать, если что-то не грузится).

Дальше поднимите новый домен параллельно со старым: тот же фронт, тот же бэкенд, те же переменные окружения. Если вы делаете настройку собственного домена в платформе вроде TakProsto, удобно сначала подключить домен как дополнительный, прогнать тесты и только потом переводить основной трафик.

Перед сменой DNS прогоните короткий набор проверок на новом домене:

• вход и выход из аккаунта в обычном окне и в инкогнито
• ключевая форма или оплата (если есть)
• 3-5 основных страниц, включая 404
• 2-3 API-запроса из браузера (нет ли ошибок CORS)
• корректный редирект на https и единый вариант с www или без

Переключение делайте в спокойное время, но не ночью, чтобы команда была на связи. После смены DNS старый домен оставьте рабочим: он еще будет открываться у части людей из-за кэша.

Заранее зафиксируйте план отката:

• вернуть прошлые A/CNAME-записи и TTL
• оставить старые сертификаты и редиректы без изменений
• понимать, сколько ждать: обычно до значения TTL, но у отдельных провайдеров бывает дольше

Первые 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 и неожиданные редиректы. Лучше сделать это за день, когда есть время спокойно проверить.

Перед переключением

• Сверьте DNS-записи по списку: какие A или CNAME должны вести на ваш хостинг, какие TXT нужны для подтверждений (например, для SSL или почты). Убедитесь, что нет старых записей, которые будут мешать.
• Заранее снизьте TTL (например, до 300 секунд) и дайте ему "прожить" хотя бы несколько часов. Иначе часть пользователей будет видеть старый адрес дольше.
• Проверьте выпуск SSL-сертификата до момента запуска: домен должен подтверждаться без ошибок, а сертификат должен покрывать нужные имена (например, и example.ru, и www.example.ru).
• Подготовьте редиректы: решите, какая версия основная (с www или без), и убедитесь, что весь трафик уходит на https с 301, без цепочек из 2-3 переходов.
• Если платформа поддерживает снапшоты и откат (например, как в TakProsto), сделайте контрольную точку перед изменениями, чтобы быстро вернуться назад.

После переключения важно проверить не только "открывается ли сайт", но и пользовательские сценарии, где чаще всего ломаются куки и авторизация.

Сразу после переключения и через сутки

• Откройте главную и пару внутренних страниц. Проверьте, что адресная строка сразу на https, а браузер не показывает предупреждений.
• Пройдите логин и логаут, обновите страницу, откройте личный кабинет. Если сессия слетает, проблема часто в домене или поддомене куки или в SameSite/Secure.
• Отправьте форму (регистрация, обратная связь, заказ) и проверьте, что данные реально дошли, а не "пропали" из-за CORS или неверного API URL.
• Проверьте с мобильного интернета и с домашнего Wi-Fi: это разные резолверы DNS, и расхождения всплывают именно здесь.
• Через сутки посмотрите статистику 4xx/5xx, жалобы пользователей и корректность редиректов (нет ли циклов, лишних промежуточных шагов и неожиданного ухода на старый домен). Также проверьте смешанный контент: если где-то остались 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...
• логинятся 2-3 разными пользователями и обновляют страницу
• проверяют важный сценарий (корзина, черновик, избранное)
• открывают пару старых ссылок и смотрят, что редирект 301 ведет на правильный путь

Если часть пользователей все еще видит старую версию (из-за кэша DNS или прокси), план отката простой: временно отключают редиректы и возвращают старые DNS-записи, пока разбираются. Параллельно проверяют настройки куки: домен должен соответствовать company.ru, а не старому временному адресу, иначе сессии "исчезают" после переезда.

Следующие шаги после переезда и как упростить поддержку

После того как вы переключили трафик и убедились, что сайт открывается по новому адресу, работа не заканчивается. Самое ценное сейчас - зафиксировать все, что вы настроили, чтобы через месяц это можно было быстро повторить или проверить, даже если этим займется другой человек.

Соберите в одном месте краткую "карту домена": какие DNS-записи стоят, какие редиректы включены (www и https), где выпускается сертификат, какие заголовки и правила прокси вы меняли. Для команды это часто важнее, чем сама настройка собственного домена, потому что снижает риск случайно сломать рабочую схему.

Что проверить и обновить, чтобы не было скрытых сбоев

Проблемы часто всплывают не на главной странице, а в интеграциях, где домен "зашит" в настройках. Пройдитесь по самым частым точкам:

• вебхуки и коллбеки: CRM, формы, чаты, доставка событий
• OAuth и авторизация: разрешенные redirect URI, список доверенных доменов
• платежи: домен в настройках кабинета, страницы успеха и ошибки, подписи
• письма и рассылки: ссылки в шаблонах, домен отправителя, SPF/DKIM/DMARC при необходимости
• аналитика и карты: список разрешенных доменов и источников

Отдельно заведите привычку раз в неделю или месяц смотреть срок действия SSL. Если сертификат автообновляется, все равно полезно иметь напоминание и простой способ быстро проверить, что цепочка сертификатов отдается корректно.

Безопасные изменения в будущем

Перед крупными правками (новые редиректы, смена CDN, правки заголовков) делайте снимок конфигурации. Если вы собираете приложение на TakProsto, заранее подключайте домен через платформу и пользуйтесь снимками и откатом: так проще вернуться к рабочему состоянию за минуты, а не вспоминать, что именно меняли на сервере и в панели домена.

Если нужен быстрый ориентир, где хранить все решения по домену, сертификатам и откату, удобно вести одну короткую страницу в рабочей документации. А в проектах на takprosto.ai этот же подход хорошо сочетается с "планированием" и снапшотами: меньше ручных действий в последний момент и меньше шансов забыть мелочь, которая сломает логин или редиректы.