Kierowanie własnej domeny na serwer tagowania: CNAME, certyfikat i błąd 1014 Cloudflare

Dwa powody, i są różne. Dla blokera reklam żądanie jest zewnętrzne, jeśli jego nazwa hosta jest na liście — signalhost.io dziś na żadnej nie jest, ale jutro może być; twojastrona.pl nie będzie nigdy. Dla przeglądarki ciasteczko ustawione przez odpowiedź z metrics.twojastrona.pl jest ciasteczkiem własnym dla twojastrona.pl, podczas gdy ciasteczko z innej domeny jest ciasteczkiem stron trzecich, a Safari po prostu je odrzuca. To właśnie ono przechowuje kliknięcie reklamy dla Google Ads, Meta i TikToka aż do zakupu. Dłuższego życia mu to nie daje: Safari nadal ogranicza do siedmiu dni ciasteczka ustawione przez serwer o innym adresie. Serwer tagowania jest w obu przypadkach ten sam. To nazwa hosta zmienia sposób, w jaki jest traktowany.

Konfigurujesz serwer tagowania od zera? Jak skonfigurować Google Tag Manager po stronie serwera, krok po kroku.

Jeden CNAME u Twojego dostawcy DNS, kierujący wybraną subdomenę na nasz punkt wejścia tylko-DNS:

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

Nie na Twoją losową nazwę hosta najemcy i nie na wildcard. tenants.signalhost.io to nazwa, którą publikujemy specjalnie w tym celu, a powód, dla którego musi to być właśnie ta nazwa, jest w następnej sekcji.

Jeśli Twoja własna domena jest w Cloudflare, utwórz rekord z WYŁĄCZONYM proxy — szara chmurka, „DNS only”. Rekord z proxy kierowałby żądania Twoich odwiedzających przez Twoje konto Cloudflare do nas, a krok z certyfikatem poniżej nie może się przez nie zakończyć.

Nasze własne nazwy hostów stoją za Cloudflare. Jeśli klient skieruje swój CNAME na jedną z naszych nazw z proxy — wildcard albo nazwę hosta najemcy — jego ruch trafia do Cloudflare dla nazwy hosta należącej do innego konta Cloudflare niż nasze. Cloudflare odrzuca to błędem 1014, „CNAME Cross-User Banned”. Strona, która go pokazuje, należy do Cloudflare, nie wspomina o żadnym z nas, a nic w Twoim DNS, Twojej stronie ani przeglądarce go nie wyjaśnia.

tenants.signalhost.io celowo nie ma proxy: rozwiązuje się bezpośrednio na nasze serwery, więc CNAME na niego po prostu działa. Sprawdzenie DNS w panelu rozpoznaje po nazwie przypadek celu z proxy i mówi, co zmienić, ale szybciej jest w ogóle do tego nie dopuścić.

Gdy tylko rekord się rozwiązuje, wnioskujemy o certyfikat Let's Encrypt dla Twojej nazwy hosta. Walidacja to HTTP-01: Let's Encrypt pobiera z tej nazwy konkretną ścieżkę zwykłym HTTP na porcie 80, a my na nią odpowiadamy. Zwykłym HTTP, bo certyfikatu jeszcze nie ma — to właśnie on jest uzyskiwany — i to jedyna nieszyfrowana ścieżka, na jaką nasz edge w ogóle odpowiada. To porównanie nonce; nic więcej nie jest tą drogą osiągalne.

Licz na kilka minut. Panel pokazuje trzy kroki po kolei: CNAME się rozwiązuje, certyfikat zostaje wydany, nazwa hosta serwuje. Krok zatrzymany na certyfikacie przy zielonym CNAME niemal zawsze oznacza rekord z proxy po Twojej stronie — Cloudflare odpowiada na żądanie walidacyjne własnym certyfikatem i własną stroną, a Let's Encrypt widzi nie to, co trzeba.

Tag Google w Twoim kontenerze internetowym zawiera adres URL kontenera serwerowego. Gdy nazwa hosta zaczyna serwować, przepisujemy go na Twoją domenę własną i ponownie publikujemy kontener — i przepisujemy z powrotem na nazwę hosta najemcy, jeśli usuniesz domenę. Od tej chwili Twoje trafienia są wysyłane na Twoją własną domenę.

Jedno musisz zrobić sam: fragment kodu na Twojej stronie nadal ładuje Tag Managera z Twojego adresu signalhost.io. Wciąż działa, ale to jedyne żądanie, które lista filtrów mogłaby jeszcze dopasować, więc go wymień. Strona kontenera pokazuje nowy fragment kodu, gdy tylko domena zaczyna serwować, a w tej samej chwili wysyłamy go do Ciebie e-mailem. Zastąp nim stary, zamiast dodawać drugi: dwa fragmenty ładują kontener dwukrotnie.

Usunięcie domeny przebiega tak samo, tylko w odwrotnej kolejności. Usuń ją w panelu, umieść z powrotem na swojej stronie fragment kodu, który wtedy pokaże strona kontenera — znów ładuje się z Twojego adresu signalhost.io — a rekord DNS usuń na końcu. Usuń najpierw rekord, a do czasu, aż panel to zauważy, Twoja strona ładuje swoje tagi z nazwy, która już się nie rozwiązuje.

• Błąd 1014 w przeglądarce: CNAME wskazuje naszą nazwę z proxy. Zmień cel na tenants.signalhost.io.
• CNAME zielony, certyfikat w toku dłużej niż piętnaście minut: Twój rekord ma proxy. Przełącz chmurkę na szarą u dostawcy DNS.
• CNAME nigdy nie robi się zielony: poszukaj konfliktowego rekordu A lub AAAA pod tą samą nazwą — CNAME nie może z nimi współistnieć — i daj propagacji do godziny.
• Serwuje, ale strona kontenera nie pokazuje ruchu z nowej nazwy: kontener internetowy nie został jeszcze ponownie opublikowany. Dzieje się to w ciągu paru minut od uruchomienia nazwy hosta; strona kontenera pokazuje, na którą nazwę hosta tag obecnie wskazuje.
• Serwuje, ale Twoja strona nadal ładuje Tag Managera z signalhost.io: na stronie wciąż jest stary fragment kodu. Zastąp go tym ze strony kontenera.