Что проверить, если SSL вашего домена не работает

Если кастомный домен показывает предупреждение «Не защищено» после того, как вы направили DNS на платформу, скорее всего, записи DNS в порядке, а рукопожатие между вашим хостом и центром сертификации застряло. Многие агентства думают, что это баг платформы, но почти всегда дело в гонке конфигураций: домен технически указывает куда нужно, а настройки маршрутизации хостов в Mydrop всё ещё ищут прежнее назначение.

Мы понимаем. Клиент ждёт, брендовый портал готов к запуску, а URL выдаёт ошибку безопасности. Именно такие узкие места превращают гладкий запуск кампании в напряжённое техническое противостояние с IT-отделом. Вы не одни: мы видели это на сотнях брендовых запусков. Виновата редко сама платформа, чаще «фантомная» запись или зависшее назначение, которое нужно снять, прежде чем управляемый SSL завершит работу.

Что изменилось до того, как сдвинулись цифры

Большинство задержек подготовки SSL начинается с маленького безобидного изменения в панели управления DNS. Вы могли обновить запись CNAME, чтобы она указывала на хост Mydrop, но если осталась устаревшая запись A или высокое значение TTL (время жизни), глобальный кэш DNS ещё несколько часов будет отдавать старые маршруты.

Настоящие проблемы начинаются, когда вы пытаетесь ускорить исправление. Многие команды без конца жмут «Обновить SSL», думая, что будят систему. На деле вы часто прерываете автоматическую фоновую задачу, которая уже была на полпути к завершению.

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

Чек-лист здоровья DNS/SSL из 5 пунктов

1. Проверка распространения: записи CNAME полностью разошлись по глобальным серверам имён? (Проверьте через инструмент вроде DNSChecker).
2. Чистота записей: удалили ли вы все старые записи A, которые направляют домен на прежний сервер?
3. Блокировка назначения: не назначен ли домен сейчас на другую активную поверхность в Mydrop?
4. Конфликт хоста: не занят ли домен другим рабочим пространством или зарезервированным публичным хостом?
5. Окно подготовки: дали ли вы хотя бы 15 минут автоматической задаче, чтобы она заметила новый статус DNS, прежде чем вмешиваться вручную?

Если статус DNS подтверждён, а sslState всё ещё показывает ошибку, скорее всего, дело в конфликте назначения. Так бывает, когда платформа пытается выпустить сертификат для домена, который одновременно указывает на поверхность link-in-bio и на поверхность brand-portal.

Снимите конфликт, полностью отвязав домен в настройках домена, снова убедитесь в статусе «DNS подтверждён» и назначьте его на нужную цель. Считайте это жёстким сбросом для слоя маршрутизации хостов: он очищает кэш маршрутов, и жизненный цикл управляемого SSL начинается заново.

У большинства команд нет технической поломки, есть рассинхрон: конфигурация домена и маршрутизация платформы просто не совпадают. Как только вы проверили запись, дайте системе завершить рукопожатие. Терпение, ваш лучший диагностический инструмент.

Какие сбои проверять в первую очередь

Когда домен застревает в состоянии «Не защищено», проблема почти всегда сводится к гонке между вашей записью DNS и нашим сервисом подготовки. Агентства на этом спотыкаются постоянно. Вы обновляете DNS, жмёте кнопку в панели и ждёте мгновенного рукопожатия. Но DNS, штука капризная: он часто расходится частично, и одни серверы уже видят ваш новый CNAME, а другие всё ещё смотрят на старую инфраструктуру или в пустоту.

Самый частый виновник, незаметная устаревшая запись. Вы обновили CNAME для portal.clientbrand.com, но забыли удалить старую запись A, указывающую на прежний сервер. Получается раздвоение. Когда наш сервис управляемого SSL пытается подтвердить владение, он иногда попадает на старый сервер вместо нашего слоя маршрутизации, и подготовка завершается по таймауту.

Частая ошибка: полагаться на кнопку обновления в браузере. Браузер агрессивно кэширует ответы DNS. Очистите кэш или, что лучше, проверьте на стороне сервера, прежде чем решать, что запись уже живёт глобально.

Ещё один частый блокер, конфликтующее назначение. Если домен раньше указывал на другое рабочее пространство или был зарезервирован как системный хост, внутренняя логика маршрутизации заблокирует SSL из соображений безопасности. Она не даст привязать сертификат к хосту, который не полностью принадлежит вашему текущему рабочему пространству. Вы застреваете в статусе «в ожидании», который никогда не снимется, потому что служба маршрутизации по сути говорит: «Я пока не признаю это твоим».

---

Доказательство, которое отделяет сигнал от шума

Хватит гадать, «тормозит ли платформа», начните проверять реальный сигнал. Именно для этого мы сделали внутренний инструмент проверки DNS, единый источник правды. Если он возвращает статус «в ожидании» или «конфликт», сколько ни жми «Обновить SSL», результат не изменится.

Используйте этот чек-лист здоровья DNS/SSL из 5 пунктов, чтобы быстро провести аудит, прежде чем открывать тикет в поддержку или дёргать разработчиков.

Шаг	Что проверяем	Что делать при сбое
1	Разошедшийся CNAME	Через dig или nslookup убедитесь, что запись указывает на наш хост, а не на старый сервер.
2	Нет конфликтующих записей A	Удалите все записи A для того же поддомена. Они причина таймаутов рукопожатия №1.
3	Доступность хоста	Убедитесь, что хост не назначен на другое рабочее пространство в ваших настройках.
4	Сигнал состояния SSL	Проверьте в панели конкретные коды sslError: DNS_PENDING значит ждите, AUTH_FAILURE значит чините записи.
5	Синхронизация задачи	Подождите минимум 15 минут. Наши фоновые задачи опрашивают статус домена, а ручное обновление иногда сбрасывает этот таймер.

Золотое правило SSL: если проверка DNS не прошла, подготовка SSL фактически на паузе. Платформа не станет запрашивать сертификат для домена, принадлежность которого не может однозначно подтвердить. Считайте проверку DNS привратником. Как только она зелёная, жизненный цикл управляемого SSL запускается сам. Если видите ошибку DNS_PENDING, это почти наверняка задержка распространения, отойдите, возьмите кофе и дайте сети догнать. Если видите AUTH_FAILURE, у вас конфигурационный фантом, и его нужно найти в консоли вашего DNS-провайдера.

Что исправить на этой неделе

Если вы сейчас смотрите на неудачный статус SSL, перестаньте жать кнопку и начните с записей DNS. Самое частое исправление на удивление простое: убедитесь, что ваши записи CNAME или A не конфликтуют с фантомным хостом. Часто старая запись A, указывающая на прежний сервер или на редирект корневого уровня, всё ещё активна у вашего DNS-провайдера, и наш сервис подготовки упирается в стену.

Расчистите путь, проверив настройки DNS. Если вы управляете кастомным доменом через Mydrop, убедитесь, что CNAME указывает точно на публичную цель кастомного домена из настроек вашего рабочего пространства. Если он указывает куда-то ещё, наш жизненный цикл управляемого SSL не сможет подтвердить владение, и подготовка зависнет навсегда.

Чек-лист восстановления DNS и SSL из 5 шагов

1. Проверьте дубли записей: удалите конфликтующие записи A или AAAA, которые могут соперничать с вашим CNAME за один и тот же хост.
2. Сверьте цель: убедитесь, что CNAME указывает точно на публичную цель, указанную в настройках домена.
3. Подождите распространения: дайте интернету догнать. Изменения DNS занимают несколько минут, а в редких случаях с упрямыми глобальными резолверами, до часа.
4. Снимите конфликты хостов: убедитесь, что ни другое рабочее пространство, ни неактивный портал сейчас не занимают тот же хост.
5. Обновите вручную: когда записи точно чистые, запустите ручное обновление в настройках домена Mydrop.

Если записи очищены, а ошибка осталась, проверьте, не является ли хост зарезервированным публичным или уже назначенным другому рабочему пространству. Это частая история в больших командах: один отдел «одолжил» домен под лендинг полгода назад и забыл его освободить.

---

Когда пора перестать диагностировать и поменять процесс

Если вы разбираетесь с SSL-сертификатами чаще раза в месяц, у вас проблема координации, а не техники. Лучшие команды не ждут предупреждения «Не защищено», чтобы понять, что домен настроен неверно. Они строят культуру «сначала проверь», где подготовка домена, отдельная, контролируемая фаза жизненного цикла проекта.

Большинство агентств совершают ошибку: отдают брендовый URL клиенту до того, как DNS полностью разошёлся и SSL заработал. Это создаёт напряжённое узкое место, когда клиент открывает ссылку и видит предупреждение браузера прямо в момент запуска. Вместо этого поменяйте внутреннюю привычку: считайте «Домен готов» обязательной галочкой, прежде чем страница link-in-bio или клиентский портал попадёт в презентацию кампании.

Правило оператора: никогда не включайте кастомный домен в коммуникацию с клиентом или в график запуска, пока проверка DNS в Mydrop не вернёт подтверждённый статус «Проверен».

Перенеся проверку на более ранний этап, вы снимаете стресс последней минуты с погоней за обновлениями DNS. Подготовка SSL превращается из технического противостояния в рутинный автоматический фоновый процесс. Когда правило «сначала проверь» становится стандартом, вы перестаёте быть IT-саппортом для собственных маркетинговых поверхностей и становитесь командой, которая запускает всё вовремя, каждый раз.

Заключение

Сбои SSL в мультиарендной среде вроде Mydrop почти никогда не связаны с поломкой платформы. Это следствие записи DNS, которая не совсем совпадает с ожидаемой маршрутизацией хоста, или гонки конфигураций, когда домен тянут в две стороны. Как только вы понимаете, что SSL, лишь финальное рукопожатие в длинной цепочке проверки DNS, «состояние ошибки» перестаёт быть загадкой. Проверьте записи, уберите фантомы и введите правило «сначала проверь» для каждого нового брендового портала. Ваша команда и ваши клиенты оценят бесшовный опыт: сайт защищён, брендирован и готов к работе с первой секунды, как только они на него попали.