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

Две причины, и они разные. Для блокировщика рекламы запрос сторонний, если его имя хоста есть в списке; signalhost.io сегодня нет ни в одном, но завтра он там может оказаться; yoursite.com не окажется никогда. Для браузера cookie, установленный ответом от metrics.yoursite.com, — это cookie первого лица для yoursite.com, тогда как cookie с другого домена — сторонний, и Safari его вовсе не принимает. Именно этот cookie хранит клик по объявлению для Google Ads, Meta и TikTok до самой покупки. Более долгой жизни это не даёт: Safari по-прежнему ограничивает семью днями cookie от сервера с другим адресом. Сервер тегинга в обоих случаях один и тот же. Имя хоста — вот что меняет отношение к нему.

Настраиваете сервер тегинга с нуля? Как настроить серверный Google Tag Manager: пошаговое руководство.

Одна 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 серверного контейнера. Когда имя хоста начинает обслуживаться, мы переписываем его на ваш пользовательский домен и переиздаём контейнер — и переписываем обратно на имя хоста арендатора, если вы удаляете домен. С этого момента ваши обращения идут на ваш собственный домен.

Одно остаётся за вами: сниппет на вашем сайте по-прежнему загружает Tag Manager с вашего адреса signalhost.io. Он продолжает работать, но это единственный запрос, который ещё может попасть под список фильтров, поэтому замените его. Страница контейнера показывает новый сниппет, как только домен начинает обслуживаться, и в тот же момент мы отправляем его вам по электронной почте. Замените его, а не добавляйте второй: два сниппета загружают контейнер дважды.

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

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