Направить собственный домен на сервер тегинга: CNAME, сертификат и ошибка Cloudflare 1014

Две причины, и они разные. Для блокировщика рекламы запрос сторонний, если его имя хоста есть в списке; signalhost.io сегодня нет ни в одном, но завтра он там может оказаться; yoursite.com не окажется никогда. Для браузера cookie, установленный ответом от metrics.yoursite.com, — это cookie первого лица для yoursite.com, с более долгим сроком жизни, который из этого следует, тогда как cookie с другого домена урезается или отклоняется. Сервер тегинга в обоих случаях один и тот же. Имя хоста — вот что меняет отношение к нему.

Одна CNAME у вашего DNS-провайдера, направляющая выбранный поддомен на нашу конечную точку «только DNS»:

metrics.yoursite.com.   CNAME   tenants.signalhost.io.

Не на ваше случайное имя хоста арендатора и не на wildcard. tenants.signalhost.io — имя, которое мы публикуем специально для этого, а почему это должно быть именно оно — в следующем разделе.

Если ваш собственный домен на Cloudflare, создайте запись с ВЫКЛЮЧЕННЫМ прокси — серое облако, «DNS only». Проксируемая запись направляла бы запросы ваших посетителей через ваш аккаунт Cloudflare к нам, и шаг с сертификатом ниже через неё завершиться не может.

Наши собственные имена хостов стоят за Cloudflare. Если клиент направит свою CNAME на одно из наших проксируемых имён — wildcard или имя хоста арендатора — его трафик придёт в Cloudflare для имени хоста, принадлежащего другому аккаунту Cloudflare, не нашему. Cloudflare отказывает в этом с ошибкой 1014, «CNAME Cross-User Banned». Страница с ней — страница Cloudflare, она не упоминает ни нас, ни вас, и ничто в вашем DNS, на вашем сайте или в браузере её не объясняет.

tenants.signalhost.io намеренно не проксируется: он резолвится прямо на наши серверы, так что CNAME на него просто работает. DNS-проверка в панели распознаёт случай проксируемой цели по имени и говорит, что изменить, но быстрее вообще до него не доводить.

Как только запись резолвится, мы запрашиваем сертификат Let's Encrypt для вашего имени хоста. Проверка — HTTP-01: Let's Encrypt запрашивает определённый путь по обычному HTTP на порту 80 с этого имени, и мы на него отвечаем. Обычный HTTP — потому что сертификата ещё нет, именно он и получается, — и это единственный нешифрованный путь, на который наш край вообще отвечает. Это сравнение nonce; ничего другого этим путём не достичь.

Рассчитывайте на несколько минут. Панель показывает три шага по порядку: CNAME резолвится, сертификат выпущен, имя хоста обслуживается. Шаг, застрявший на сертификате при зелёной CNAME, почти всегда означает проксируемую запись на вашей стороне — Cloudflare отвечает на запрос проверки собственным сертификатом и собственной страницей, и Let's Encrypt видит не то.

Тег Google в вашем веб-контейнере несёт URL серверного контейнера, и мы переписываем его на пользовательский домен и переиздаём контейнер, когда имя хоста начинает обслуживаться, — и переписываем обратно на имя хоста арендатора, если вы удаляете домен. Сниппет на вашем сайте не меняется; он загружает контейнер, а контейнер знает, куда отправлять.

Поэтому порядок удаления важен. Сначала удалите домен в панели, затем удалите DNS-запись. Удалите запись первой — и, пока панель не заметит, контейнер по-прежнему направляет ваших посетителей на имя, которое больше не резолвится.

• Ошибка 1014 в браузере: CNAME указывает на наше проксируемое имя. Смените цель на tenants.signalhost.io.
• CNAME зелёная, сертификат в ожидании больше пятнадцати минут: ваша запись проксируется. Сделайте облако серым у DNS-провайдера.
• CNAME никогда не становится зелёной: проверьте, нет ли конфликтующей записи A или AAAA на том же имени — CNAME не может сосуществовать с ними — и дайте распространению до часа.
• Обслуживается, но страница контейнера не показывает трафика с нового имени: веб-контейнер ещё не переиздан. Это происходит в течение пары минут после того, как имя хоста заработало; страница контейнера показывает, на какое имя хоста тег указывает сейчас.