Настройка собственного домена для веб‑приложения: шаги по DNS, выпуск SSL, правила редиректов и план низкорискового переключения, чтобы избежать простоя и проблем с куки.
Собственный домен — это не просто более красивый URL. Как только вы переходите с адреса платформы (например, приложение на Koder.ai с подплодоменом платформы) на свой домен, браузеры и сети начинают воспринимать это как другой сайт. Это влияет на маршрутизацию, безопасность и поведение сессий пользователей.
После переключения на собственный домен сразу меняется несколько вещей:
www или на корневой домен, и нужны ли согласованные правила HTTP → HTTPS.old-platform.example не будет автоматически работать на app.yourdomain.com.Короткие простои обычно связаны с таймингом. DNS может начать отправлять трафик на новый хост раньше, чем будет готов SSL, и браузеры покажут предупреждения. Или наоборот: SSL готов, а многие пользователи всё ещё попадают на старый хост из‑за кеша DNS.
Редиректы тоже могут тонко ломать логины. Редирект, меняющий имя хоста (apex → www или наоборот), может «потерять» куки, если они были выставлены для другого хоста. Провайдеры аутентификации могут падать, если их callback URL всё ещё указывает на старый домен.
Низкорисковое переключение означает планирование перекрытия: держите старый URL рабочим, поднимите новый домен параллельно, переключайте трафик в предсказуемый момент и сделайте откат простым — вернуть DNS назад.
Прежде чем что‑то менять, запишите точно, какие имена вы хотите, чтобы пользователи вводили, а какие должны тихо перенаправлять. Большинство «почему это работает наполовину?» случаются потому, что команда не договорилась об одном каноническом хосте.
Начните с главного выбора: корневой (apex) (example.com) или www (www.example.com) как основной. Оба варианта работают, но выберите один и относитесь к другому как к редиректу. Это важно и для куки: сессии проще, когда приложение живёт на одном согласованном хосте.
Далее решите, какие поддомены нужны сейчас, а какие можно отложить. Обычная схема: app.example.com для веб‑приложения и api.example.com для API, с admin.example.com или assets.example.com по мере необходимости. Если вы настраиваете custom домен на платформе вроде Koder.ai, эти имена напрямую соответствуют тому, что нужно подтвердить для SSL и куда указывать в DNS.
Многие регистрируют домен у регистратора, но управлять DNS может кто‑то другой. Уточните, где сейчас редактируются записи, кто имеет доступ и есть ли автоматизация (IT компании, агентство или управляемый DNS-провайдер). Если вы не можете войти и увидеть текущие записи — остановитесь и решите это в первую очередь.
Также проверьте, что уже использует домен. Почта — классическая ловушка: можно разорвать доставку почты, удалив или заменив записи.
Перед продолжением зафиксируйте эти решения письменно:
www) и направление редиректаЕсли маркетинг уже использует почту на example.com, не трогайте записи почты и добавляйте только то, что нужно приложению.
Большая часть риска при переносе домена — не в самом приложении, а в одной ошибочной DNS‑правке, которая отправит трафик в никуда, сломает почту или сделает невозможной проверку SSL.
A‑запись указывает имя на IP‑адрес. Проще: «отправляйте людей на этот сервер». Часто используется для корневого домена, когда провайдер даёт фиксированный IP.
CNAME указывает одно имя на другое имя. Проще: «рассматривайте это имя как псевдоним того хоста». Часто применяется для www.example.com, указывая на hostname платформы.
Многие DNS‑провайдеры также предлагают ALIAS/ANAME для корня. Это ведёт себя как CNAME, но работает для example.com. Если провайдер поддерживает — это удобнее, потому что цель может менять IP без ваших действий.
Проще запомнить:
Часто добавляют TXT для подтверждения владения доменом (верификация платформы) и для валидации SSL (некоторые CA проверяют через TXT‑токен). TXT также используется для политик почты, например, SPF. Случайное удаление или замена SPF TXT может сломать почту.
TTL управляет тем, как долго другие системы кешируют ответ DNS. За день до переключения понизьте TTL для записей, которые будете менять (обычно 300–600 секунд). После стабилизации поднимите его обратно, чтобы уменьшить нагрузку.
Перед правкой экспортируйте или сфотографируйте текущую зону. Запишите каждую запись, которую будете менять: старое значение, новое и TTL. Откат — это восстановление предыдущих значений.
Это особенно важно, когда домен уже имеет MX, DKIM или другие TXT для почты.
SSL (замочек) шифрует трафик между браузером и приложением. Современные браузеры и многие API по умолчанию ожидают HTTPS. Без него будут предупреждения, блокировки запросов, и такие возможности как service workers, геолокация или платежные потоки могут перестать работать.
Чтобы получить сертификат, CA должен проверить владение доменом. Частые методы валидации — HTTP‑валидация и DNS‑TXT валидация:
DNS‑валидация часто проще, когда вы используете CDN или когда приложение ещё недоступно на новом домене.
Где именно выпускается сертификат — зависит от архитектуры. Кто‑то выпускает сертификаты прямо на хостинге, кто‑то на CDN, а некоторые платформы, поддерживающие custom домены, делают это за вас (например, Koder.ai может управлять сертификатом при настройке домена). Важно знать, кто отвечает за жизненный цикл сертификата, включая продления.
Выпуск сертификата не всегда моментален. Распространение DNS, проверки валидации и ограничения по частоте могут замедлить процесс. Планируйте повторы и не назначайте переключение на самый последний момент.
Практический план по тайм‑оффлайну:
Сертификат должен покрывать каждое имя хоста, по которому попадают пользователи. Посмотрите SAN‑список (Subject Alternative Names). Если ваше приложение будет доступно и на example.com, и на www.example.com, сертификат должен включать оба.
Вайлдкарды (например, *.example.com) помогают для многих поддоменов, но не покрывают корневой домен (example.com).
Пример: если вы выпустите сертификат только для www.example.com, пользователи, вводящие example.com, увидят предупреждение, если редирект не выполняется на уровне с действительным сертификатом для example.com.
Редиректы кажутся простыми, но большинство проблем именно здесь: петли, смешанный контент и потеря логинов из‑за смены хоста.
Выберите один канонический хост и придерживайтесь его: www.example.com или example.com. Остальные точки входа должны редиректить на канонический хост, чтобы куки, сессии и SEO‑сигналы оставались целыми.
Безопасные настройки по умолчанию:
http:// на https:// для всех запросовДля HTTP → HTTPS избегайте правил, из‑за которых пользователи будут отброшены назад и снова. Самый простой способ предотвратить петли — принимать решение на основании реального запроса. Если приложение за прокси/CDN, настройте его так, чтобы он учитывал forwarded‑заголовки (например, заголовок, указывающий, что исходная схема была HTTP). Иначе приложение может думать, что каждый запрос — HTTP, и постоянно редиректить.
Во время переноса сохраняйте старые пути. Если вы меняете маршруты (например, /login → /sign-in), добавьте явные редиректы для этих путей. Не полагайтесь на общий редирект на главную — это ломает закладки и старые ссылки.
Отложите HSTS на первое время. Если включить его слишком рано, а потом понадобится HTTP для валидации или отладки, браузеры могут отказать. Включайте HSTS, когда HTTPS устойчив и вы подтвердили покрытие поддоменов.
Чтобы тестировать редиректы без влияния на всех пользователей, используйте временное тестовое имя, проверьте реальные глубокие ссылки (включая страницы авторизации) и выполните командную строку, показывающую каждый шаг редиректа и финальный адрес.
Безопасное переключение — это по большей части тайминг. Новый домен должен быть готов и протестирован до того, как на него начнёт идти реальный трафик, и вы хотите, чтобы DNS‑изменения распространялись быстро, чтобы не застрять во время инцидента.
Понизьте TTL для записей, которые будете менять, заранее. Лучше за день и подождать, пока старый TTL не истечёт, чтобы кеши успели обновиться.
Добавьте custom домен в ваш хост/провайдера и выполните требуемую верификацию. Если вы используете платформу вроде Koder.ai, сначала добавьте домен там, чтобы платформа подтвердила владение и подготовила маршрутизацию.
Выпустите SSL заранее. Сертификаты могут занимать минуты или дольше, и вы не хотите этой задержки в момент переключения.
Прежде чем делать домен общедоступным, проведите приватный тест: обратитесь к новому эндпоинту способом, который не зависит от публичного DNS (например, временная запись в hosts на вашей машине) и убедитесь, что сайт загружается по HTTPS с правильным сертификатом.
Используйте поэтапный подход, чтобы быстро остановиться при проблемах:
www) перед переключением пользователей.Если нельзя сделать полноценный canary на уровне DNS, можно поэтапно переключать только одно имя хоста (например, сначала www), оставив корень нетронутым до уверенности.
Запишите, что конкретно вы будете откатывать (какие записи, какие значения) и кто этим займётся. Откат обычно — вернуть DNS как было.
Убедитесь, что старая конфигурация всё ещё действительна (включая SSL), чтобы пользователи могли без проблем вернуться, пока вы исправляете новый путь.
Смена домена — это не только правка DNS. Для многих приложений «быть залогиненным» зависит от куки, которые браузеры привязывают к конкретному хосту. При переходе на другой хост браузер может перестать отправлять старые куки, и приложение выглядит так, будто всех разлогинило.
Обычно проблемы в настройках куки:
app.old.com не будут отправляться на app.new.com. Кука для .example.com работает на app.example.com и www.example.com./api), UI может не видеть куку.Lax часто подходит, но для некоторых SSO или платежных редиректов нужен None + Secure.Чтобы снизить риск, планируйте короткий переходный период, когда оба домена работают. Держите старый хост отвечающим и аккуратно перенаправляйте, но позволяйте обновлять сессии на новом домене. Если можете, используйте общий стор сессий, чтобы пользователь, попавший на любой из хостов, узнавался.
Если вы используете SSO или OAuth — обновите настройки перед переключением: callback URL, разрешённые origin и allowlist для redirect URI. Иначе логин может пройти у провайдера, но упасть по возвращении в приложение.
Тестируйте сначала потоки, которые обычно ломаются: регистрация (и подтверждение по почте), вход/выход, сброс пароля, возврат из платежа и сессии в нескольких вкладках.
Пример: если вы редиректите www.example.com → example.com, убедитесь, что куки выставлены для .example.com (или используйте единый хост). Иначе пользователи будут прыгать между хостами и терять сессию.
Большинство проблем с доменом — не «таинственные интернет‑ошибки», а небольшие несоответствия между DNS, сертификатами и правилами редиректа, видимые только при реальной нагрузке.
Одна распространённая ловушка — корневой домен (example.com). Многие DNS‑провайдеры не позволяют делать настоящий CNAME на корне. Если попытаться, это может тихо провалиться, разрешаться непоследовательно или ломаться в некоторых сетях. Используйте то, что поддерживает ваш DNS (обычно A/AAAA или ALIAS/ANAME).
Ещё одна частая причина простоя — поменять DNS раньше, чем SSL будет готов на новом эндпоинте. Пользователи приходят, приложение грузится, и браузер блокирует доступ из‑за отсутствия сертификата или покрытий не на все хосты. На практике обычно хорошо, если сертификат покрывает и example.com, и www.example.com, даже если планируете редирект одного на другой.
Типичные ошибки, приводящие к простоям или странностям:
www → apex, потом apex обратно → www) или заставляющие HTTP в одном месте и HTTPS в другомhttp:// для ресурсов, что вызывает предупреждения браузера и поломкиБыстрая проверка здравого смысла: откройте оба хоста (www и корень) по HTTPS, залогиньтесь, обновите страницу и убедитесь, что адресная строка не возвращается к HTTP.
Если вы делаете это на платформе вроде Koder.ai, убедитесь, что custom домены подключены и SSL выдан до правки production DNS, и держите план отката, чтобы плохой редирект или изменение записи не висели долго.
Спокойный переключатель — это большая подготовка. Цель проста: пользователи должны оставаться залогиненными, куки должны работать, а откат должен быть быстрым, если что‑то пойдёт не так.
Делайте это пока трафик идёт на старый домен. Дайте себе день, если можно, чтобы DNS‑изменения успели распространиться.
www, api и т.д.) и выберите метод валидации SSL (DNS или HTTP).www → apex (или наоборот) и один канонический хост.Когда вы меняете DNS, первые час рассматривайте как учение по инцидентам. Наблюдайте реальные пользовательские потоки, не только дашборды состояния.
Даже если Koder.ai (или другая платформа) управляет custom доменами и SSL, этот чеклист всё равно важен. Большинство проблем — из‑за DNS и редиректов, а не кода приложения.
Ваше приложение работает на временном адресе платформы, например myapp.koder.ai. Всё работает, но вы хотите, чтобы пользователи использовали example.com, при этом www.example.com редиректил на корень, и всё было по HTTPS.
Простой DNS‑план снижает риски. До правки сделайте снимок текущего состояния (если платформа поддерживает), и за день понизьте TTL до короткого значения.
Добавьте новые записи, оставив рабочий адрес платформы нетронутым:
example.com: A/ALIAS запись, указывающая на таргет хостинга, предоставленный платформойwww.example.com: CNAME, указывающий на example.com (или на таргет платформы в зависимости от провайдера)myapp.koder.ai как есть, чтобы всегда был известный рабочий fallbackКогда DNS настроен, запросите SSL для обоих имён (example.com и www.example.com). Не переключайте трафик до тех пор, пока сертификат не выпущен и не активен, иначе пользователи увидят предупреждения.
Таймлайн переключения с контрольными точками:
example.com в режиме инкогнито (главная, статические ресурсы, вызовы API)www → apex)После переноса проверьте поведение куки: залогиньтесь, обновите страницу и убедитесь, что остаётесь залогиненными на www и на корне. Если сессии ломаются — обычно это настройки domain или SameSite, которые всё ещё предполагают старый хост.
После успешного переключения работа не заканчивается. Большинство проблем появляется позже из‑за «дрейфа»: сертификат близок к истечению, поспешная DNS‑правка или правка редиректа ломают авторизацию.
Настройте простой рутинный мониторинг, который вы реально поддержите. Не нужен корпоративный инструмент сразу, но нужны надёжные сигналы: проверки доступности ключевых страниц (главная, вход и одна аутентифицированная страница), оповещения о сроке действия сертификата (например, за 30 и за 7 дней), слежение за ошибками (всплески 4xx/5xx) и периодическая проверка редиректов (HTTP → HTTPS и победитель по hostname).
Держите короткое окно отката ещё 24–72 часа. Наблюдайте старую конфигурацию (старые DNS‑таргеты, старые настройки хостинга, старые TLS‑настройки), чтобы быстро вернуть, если проявится скрытая проблема (например, callback платёжного провайдера или OAuth всё ещё указывает на старый домен).
Когда уверены, поднимите TTL обратно. Низкий TTL полезен при изменениях, но он увеличивает нагрузку и повышает риск мелких ошибок. Выберите нормальный TTL по частоте запланированных изменений (многие команды берут 1–4 часа).
И наконец, задокументируйте финальное состояние, пока всё свежо: какие записи есть (тип, имя, значение, TTL), какие хосты поддерживаются, точные правила редиректа, где выписаны сертификаты и что они покрывают (апекс, www, поддомены), и кто отвечает за продление.
Если вы развертываете на платформе, полезно, когда домены — полноценная фича и откат прост. На Koder.ai custom домены идут рядом со снимками/rollback, что упрощает будущие изменения и быстрый откат при проблемах.
Default to one canonical hostname and redirect everything else to it.
example.com (apex) or www.example.com as the “real” one.This keeps cookies, sessions, and bookmarks consistent and prevents half-working behavior.
Lower TTL the day before you plan to switch, then wait long enough for the old TTL to age out.
Only lower TTL on the records you’re actually going to change.
For many app setups:
www.example.com or app.example.com when you’re pointing to a provider hostname.example.com.Don’t switch user traffic until HTTPS is valid on the new hostname(s).
A practical order:
This avoids browser warnings and blocked requests right at cutover.
Most email breakage happens when people delete or overwrite MX and TXT records.
Before changing anything:
Redirect chains and loops usually come from conflicting rules between your CDN/proxy and your app.
Use these safe defaults:
http:// → https://If you’re behind a proxy/CDN, make sure your app respects forwarded scheme headers; otherwise it may think every request is HTTP and keep redirecting forever.
Yes, it’s common if cookies were scoped to the old hostname.
What to check:
old-host won’t be sent to new-hostUpdate identity settings before cutover.
Typical items that must match the new domain exactly:
If these still point to the old domain, sign-in can succeed at the provider but fail when returning to your app.
A rollback is usually just restoring the previous DNS values.
Keep it simple:
If your platform supports snapshots/rollback (Koder.ai does), take one before cutover so you can quickly undo related configuration changes too.
Focus on real user paths, not just the homepage.
Test these on both the canonical host and the redirecting host:
Also verify the address bar ends on and always on , with no mixed-content warnings.
Avoid trying to force a CNAME at the apex if your DNS host doesn’t support an apex alias style record.
A quick safety step is exporting or screenshotting the current zone so you can restore it fast.
A low-risk approach is keeping the old hostname working during a transition so users can refresh sessions on the new domain.