ब्लॉग
टैगिंग सर्वर पर अपना डोमेन पॉइंट करना: CNAME, सर्टिफ़िकेट और Cloudflare error 1014
प्रकाशित · अपडेट किया गया · पढ़ने में 5 मिनट
हमसे मिलने वाला पहला होस्टनेम signalhost.io के नीचे एक रैंडम लेबल होता है। यह काम करता है, और कई साइटों के लिए काफ़ी है — यह पहले से ही googletagmanager.com नहीं है। लेकिन फ़िल्टर लिस्ट और थर्ड-पार्टी कुकी नियमों से बच निकलने वाला रूप आपके अपने डोमेन का सबडोमेन है, क्योंकि ब्राउज़र के लिए वह बस आपकी ही साइट है। वहाँ तक पहुँचने में एक DNS रिकॉर्ड और कुछ मिनट लगते हैं। इसमें ज़रा-सी भी चूक हो, तो ऐसा एरर मैसेज आता है जिसे आपकी तरफ़ की कोई भी चीज़ समझा नहीं सकती — इसलिए यहाँ पूरी प्रक्रिया है, उस नाकामी समेत।
अपनी ही साइट का सबडोमेन क्यों
दो वजहें हैं, और दोनों अलग हैं। ऐड ब्लॉकर के लिए कोई रिक्वेस्ट तब थर्ड-पार्टी है जब उसका होस्टनेम किसी लिस्ट में हो; signalhost.io आज किसी लिस्ट में नहीं है, लेकिन कल हो सकता है — yoursite.com कभी नहीं होगा। ब्राउज़र के लिए, metrics.yoursite.com के रिस्पॉन्स से सेट हुई कुकी yoursite.com की फ़र्स्ट-पार्टी कुकी है, जबकि किसी दूसरे डोमेन से आई कुकी थर्ड-पार्टी है, और Safari उसे सीधे मना कर देता है। यही वह कुकी है जो Google Ads, Meta और TikTok के लिए किसी विज्ञापन क्लिक को खरीदारी तक सँभाले रखती है। इससे कुकी की उम्र लंबी नहीं होती: किसी अलग पते वाले सर्वर से आई कुकी को Safari अब भी सात दिन तक सीमित रखता है। टैगिंग सर्वर दोनों हालात में वही रहता है। होस्टनेम ही तय करता है कि उसके साथ कैसा बर्ताव हो।
टैगिंग सर्वर शुरू से सेट कर रहे हैं? सर्वर-साइड Google Tag Manager कैसे सेट करें, कदम-दर-कदम।
रिकॉर्ड
आपके DNS प्रोवाइडर पर एक CNAME, जो आपके चुने हुए सबडोमेन को हमारे DNS-only एंडपॉइंट पर पॉइंट करे:
metrics.yoursite.com. CNAME tenants.signalhost.io.आपके रैंडम टेनेंट होस्टनेम पर नहीं, और किसी वाइल्डकार्ड पर भी नहीं। tenants.signalhost.io एक ऐसा नाम है जिसे हम खास तौर पर इसी काम के लिए प्रकाशित करते हैं, और यही नाम क्यों होना चाहिए, यह अगले सेक्शन में बताया गया है।
अगर आपका अपना डोमेन Cloudflare पर है, तो रिकॉर्ड प्रॉक्सी बंद करके बनाएँ — ग्रे क्लाउड, "DNS only"। प्रॉक्सी वाला रिकॉर्ड आपके विज़िटर की रिक्वेस्ट को आपके Cloudflare खाते से होकर हम तक भेजेगा, और नीचे बताया गया सर्टिफ़िकेट वाला स्टेप उसके ज़रिए पूरा नहीं हो सकता।
Cloudflare error 1014, और टारगेट DNS-only क्यों होना चाहिए
हमारे अपने होस्टनेम Cloudflare के पीछे हैं। अगर कोई ग्राहक अपना CNAME हमारे किसी प्रॉक्सी वाले नाम पर पॉइंट करता है — वाइल्डकार्ड पर, या किसी टेनेंट होस्टनेम पर — तो उसका ट्रैफ़िक Cloudflare पर एक ऐसे होस्टनेम के लिए पहुँचता है जो हमारे Cloudflare खाते से अलग किसी और खाते का है। Cloudflare इसे error 1014, "CNAME Cross-User Banned" के साथ मना कर देता है। जो पेज यह एरर दिखाता है वह Cloudflare का होता है, उसमें न आपका ज़िक्र होता है न हमारा, और आपके DNS, आपकी साइट या आपके ब्राउज़र में ऐसा कुछ नहीं होता जो इसकी वजह समझा सके।
tenants.signalhost.io जानबूझकर बिना प्रॉक्सी के रखा गया है: यह सीधे हमारे सर्वर पर रिज़ॉल्व होता है, इसलिए उस पर पॉइंट किया गया CNAME बस काम करता है। डैशबोर्ड का DNS चेक प्रॉक्सी वाले टारगेट के मामले को नाम से पहचानता है और बताता है कि क्या बदलना है, लेकिन सबसे तेज़ तरीका यह है कि यह गलती कभी हो ही नहीं।
सर्टिफ़िकेट
जैसे ही रिकॉर्ड रिज़ॉल्व होता है, हम आपके होस्टनेम के लिए Let's Encrypt सर्टिफ़िकेट का अनुरोध करते हैं। वैलिडेशन HTTP-01 है: Let's Encrypt उस नाम से पोर्ट 80 पर सादे HTTP के ज़रिए एक खास पाथ फ़ेच करता है, और हम उसका जवाब देते हैं। सादा HTTP इसलिए, क्योंकि अभी कोई सर्टिफ़िकेट है ही नहीं — वही तो हासिल किया जा रहा है — और यह इकलौता बिना एन्क्रिप्शन वाला पाथ है जिसका हमारा एज जवाब देता है। यह बस एक nonce की तुलना है; उस रास्ते से और कुछ भी नहीं पहुँचा जा सकता।
कुछ मिनट लगने की उम्मीद रखें। डैशबोर्ड क्रम से तीन स्टेप दिखाता है: CNAME रिज़ॉल्व होता है, सर्टिफ़िकेट जारी होता है, होस्टनेम सर्व करने लगता है। अगर CNAME हरा है और स्टेप सर्टिफ़िकेट पर अटका है, तो लगभग हमेशा इसका मतलब है कि आपकी तरफ़ का रिकॉर्ड प्रॉक्सी वाला है — Cloudflare वैलिडेशन रिक्वेस्ट का जवाब अपने सर्टिफ़िकेट और अपने पेज से देता है, और Let's Encrypt को गलत चीज़ दिखती है।
सर्व होने के बाद
आपके वेब कंटेनर के Google टैग में सर्वर कंटेनर URL होता है। जब होस्टनेम सर्व करने लगता है, तो हम इस URL को आपके कस्टम डोमेन में बदलकर कंटेनर को फिर से पब्लिश करते हैं — और अगर आप डोमेन हटाते हैं, तो इसे वापस टेनेंट होस्टनेम पर कर देते हैं। उसी पल से आपके हिट आपके अपने डोमेन पर जाते हैं।
आपके लिए एक काम बाकी रहता है: आपकी साइट पर लगा स्निपेट अब भी Tag Manager को आपके signalhost.io पते से लोड करता है। वह काम करता रहता है, लेकिन यही वह इकलौती रिक्वेस्ट है जिसे कोई फ़िल्टर लिस्ट अब भी पकड़ सकती है, इसलिए उसे बदल दें। डोमेन के सर्व होते ही कंटेनर पेज नया स्निपेट दिखाता है, और उसी पल हम उसे आपको ईमेल भी करते हैं। दूसरा स्निपेट जोड़ने के बजाय पुराने को बदलें: दो स्निपेट कंटेनर को दो बार लोड करते हैं।
डोमेन हटाना इसी का उल्टा है। उसे डैशबोर्ड में हटाएँ, उसके बाद कंटेनर पेज जो स्निपेट दिखाए उसे वापस अपनी साइट पर लगाएँ — वह फिर से आपके signalhost.io पते से लोड होता है — और DNS रिकॉर्ड सबसे आख़िर में मिटाएँ। अगर पहले रिकॉर्ड मिटा दिया, तो जब तक डैशबोर्ड इसे नोटिस नहीं करता, आपकी साइट अपने टैग एक ऐसे नाम से लोड करती है जो अब रिज़ॉल्व ही नहीं होता।
अगर काम न करे
- ब्राउज़र में error 1014: CNAME हमारे किसी प्रॉक्सी वाले नाम पर पॉइंट करता है। टारगेट को tenants.signalhost.io में बदलें।
- CNAME हरा है, लेकिन सर्टिफ़िकेट पंद्रह मिनट से ज़्यादा समय से लंबित है: आपका रिकॉर्ड प्रॉक्सी वाला है। अपने DNS प्रोवाइडर पर क्लाउड को ग्रे करें।
- CNAME कभी हरा नहीं होता: जाँचें कि उसी नाम पर कोई टकराने वाला A या AAAA रिकॉर्ड तो नहीं है — CNAME उनके साथ नहीं रह सकता — और प्रोपेगेशन के लिए एक घंटे तक का समय दें।
- सर्व हो रहा है, लेकिन कंटेनर पेज पर नए नाम से कोई ट्रैफ़िक नहीं दिखता: वेब कंटेनर अभी तक फिर से पब्लिश नहीं हुआ है। होस्टनेम के लाइव होने के कुछ ही मिनटों में ऐसा हो जाता है; कंटेनर पेज दिखाता है कि टैग अभी किस होस्टनेम पर पॉइंट करता है।
- सर्व हो रहा है, लेकिन आपकी साइट अब भी Tag Manager को signalhost.io से लोड करती है: पुराना स्निपेट अब भी पेज पर है। उसे कंटेनर पेज वाले स्निपेट से बदलें।

