وبلاگ
اتصال دامنه خودتان به سرور تگ‌گذاری: رکورد CNAME، گواهی و خطای 1014 در Cloudflare
منتشرشده · به‌روزشده · 5 دقیقه مطالعه
نخستین نام میزبانی که از ما می‌گیرید یک برچسب تصادفی زیر signalhost.io است. کار می‌کند و برای بسیاری از سایت‌ها کافی است — همین حالا هم googletagmanager.com نیست. اما زیردامنه‌ای از دامنه خودتان نسخه‌ای است که از فهرست‌های فیلتر و قواعد کوکی شخص ثالث جان سالم به در می‌برد، چون از نگاه مرورگر صرفاً سایت خود شماست. رسیدن به آن یک رکورد DNS و چند دقیقه وقت می‌گیرد. اگر کمی اشتباه انجامش دهید، پیام خطایی می‌گیرید که هیچ چیز در سمت شما توضیحش نمی‌دهد؛ پس این کل روند است، از جمله حالت خطا.
چرا زیردامنه‌ای از سایت خودتان
دو دلیل دارد، و این دو با هم فرق دارند. از نگاه مسدودکننده تبلیغات، درخواستی شخص ثالث است که نام میزبانش در یک فهرست باشد؛ signalhost.io امروز در هیچ فهرستی نیست اما ممکن است فردا باشد، و yoursite.com هرگز نخواهد بود. از نگاه مرورگر، کوکی‌ای که پاسخی از metrics.yoursite.com تنظیم می‌کند کوکی شخص اول برای yoursite.com است، در حالی که کوکیِ دامنه‌ای دیگر شخص ثالث است و Safari آن را یکسره رد می‌کند. این همان کوکی است که کلیک تبلیغ را برای Google Ads، Meta و TikTok تا لحظه خرید نگه می‌دارد. البته عمر طولانی‌تری برایش نمی‌خرد: Safari همچنان کوکی‌های سروری با نشانی متفاوت را به هفت روز محدود می‌کند. سرور تگ‌گذاری در هر دو حالت یکی است؛ این نام میزبان است که نحوه برخورد با آن را تغییر می‌دهد.
سرور تگ‌گذاری را از صفر راه‌اندازی می‌کنید؟ راه‌اندازی Google Tag Manager سمت سرور، گام‌به‌گام.
رکورد
یک رکورد CNAME نزد ارائه‌دهنده DNS شما، که زیردامنه انتخابی‌تان را به نقطه پایانی DNS-only ما اشاره می‌دهد:
metrics.yoursite.com. CNAME tenants.signalhost.io.نه به نام میزبان تصادفی خودتان و نه به یک wildcard. tenants.signalhost.io نامی است که مخصوصاً برای همین منتشر می‌کنیم، و اینکه چرا باید همین نام باشد، موضوع بخش بعدی است.
اگر دامنه خودتان روی Cloudflare است، رکورد را با پراکسی خاموش بسازید — ابر خاکستری، «DNS only». رکورد پراکسی‌شده درخواست‌های بازدیدکنندگانتان را از مسیر حساب Cloudflare شما به ما می‌رساند و مرحله گواهی که در ادامه آمده از این مسیر کامل نمی‌شود.
خطای 1014 در Cloudflare و چرا هدف رکورد باید DNS-only باشد
نام‌های میزبان خود ما پشت Cloudflare قرار دارند. اگر مشتری‌ای CNAME خود را به یکی از نام‌های پراکسی‌شده ما اشاره دهد — wildcard یا یکی از نام‌های میزبان تصادفی — ترافیکش برای نام میزبانی به Cloudflare می‌رسد که به حساب Cloudflare دیگری غیر از حساب ما تعلق دارد. Cloudflare این را با خطای 1014، «CNAME Cross-User Banned»، رد می‌کند. صفحه‌ای که این خطا را نشان می‌دهد مال Cloudflare است، نامی از هیچ‌کدام از ما نمی‌برد و هیچ چیز در DNS، سایت یا مرورگر شما آن را توضیح نمی‌دهد.
نام tenants.signalhost.io عمداً بدون پراکسی است: مستقیماً به نشانی سرورهای ما می‌رسد، پس رکورد CNAME که به آن اشاره کند به‌سادگی کار می‌کند. بررسی DNS در داشبورد حالتِ هدفِ پراکسی‌شده را به‌طور مشخص تشخیص می‌دهد و می‌گوید چه چیزی را تغییر دهید، اما سریع‌تر این است که اصلاً این اشتباه را نکنید.
گواهی
وقتی رکورد در DNS پاسخ داد، برای نام میزبان شما یک گواهی Let's Encrypt درخواست می‌کنیم. اعتبارسنجی از نوع HTTP-01 است: Let's Encrypt مسیر مشخصی را از طریق HTTP ساده روی پورت 80 از آن نام دریافت می‌کند و ما پاسخش را می‌دهیم. HTTP ساده، چون هنوز گواهی‌ای وجود ندارد — اصلاً همان چیزی است که در حال دریافتش هستیم — و این تنها مسیر رمزنگاری‌نشده‌ای است که لبه (edge) ما به آن پاسخ می‌دهد. این فقط مقایسه یک nonce است؛ هیچ چیز دیگری از این راه در دسترس نیست.
چند دقیقه طول می‌کشد. داشبورد سه مرحله را به‌ترتیب نشان می‌دهد: CNAME پاسخ می‌دهد، گواهی صادر می‌شود، نام میزبان در حال سرویس‌دهی است. اگر مرحله گواهی گیر کرده و CNAME سبز است، تقریباً همیشه یعنی رکورد در سمت شما پراکسی‌شده است — Cloudflare به درخواست اعتبارسنجی با گواهی و صفحه خودش پاسخ می‌دهد و Let's Encrypt چیز اشتباهی می‌بیند.
پس از شروع سرویس‌دهی
تگ Google در کانتینر وب شما URL کانتینر سرور را در خود دارد. وقتی نام میزبان شروع به سرویس‌دهی کند، آن را به دامنه اختصاصی شما تغییر می‌دهیم و کانتینر را دوباره منتشر می‌کنیم — و اگر دامنه را حذف کنید، آن را به نام میزبان signalhost.io شما برمی‌گردانیم. از همان لحظه هیت‌های شما به دامنه خودتان می‌روند.
یک کار برای شما می‌ماند: قطعه‌کد روی سایتتان هنوز Tag Manager را از نشانی signalhost.io شما بارگذاری می‌کند. همچنان کار می‌کند، اما تنها درخواستی است که یک فهرست فیلتر هنوز می‌تواند آن را شناسایی کند؛ پس آن را جایگزین کنید. صفحه کانتینر به‌محض اینکه دامنه سرویس‌دهی را شروع کند قطعه‌کد جدید را نشان می‌دهد و ما همان لحظه آن را برایتان ایمیل می‌کنیم. آن را جایگزین کنید، نه اینکه قطعه‌کد دومی اضافه کنید: دو قطعه‌کد، کانتینر را دو بار بارگذاری می‌کنند.
حذف دامنه همین روند به‌صورت معکوس است. آن را در داشبورد حذف کنید، قطعه‌کدی را که صفحه کانتینر در آن زمان نشان می‌دهد دوباره روی سایتتان بگذارید — که باز از نشانی signalhost.io شما بارگذاری می‌شود — و رکورد DNS را در آخر پاک کنید. اگر اول رکورد را پاک کنید، تا وقتی داشبورد متوجه شود، سایت شما تگ‌هایش را از نامی بارگذاری می‌کند که دیگر در DNS وجود ندارد.
اگر کار نکرد
- خطای 1014 در مرورگر: CNAME به یکی از نام‌های پراکسی‌شده ما اشاره می‌کند. هدف را به tenants.signalhost.io تغییر دهید.
- CNAME سبز است اما گواهی بیش از پانزده دقیقه در انتظار مانده: رکورد شما پراکسی‌شده است. ابر را نزد ارائه‌دهنده DNS خود خاکستری کنید.
- CNAME هرگز سبز نمی‌شود: بررسی کنید رکورد A یا AAAA متعارضی روی همان نام وجود نداشته باشد — CNAME نمی‌تواند در کنار آن‌ها وجود داشته باشد — و برای انتشار تغییرات تا یک ساعت فرصت بدهید.
- سرویس‌دهی برقرار است اما صفحه کانتینر هیچ ترافیکی از نام جدید نشان نمی‌دهد: کانتینر وب هنوز دوباره منتشر نشده است. این کار ظرف چند دقیقه پس از فعال شدن نام میزبان انجام می‌شود؛ صفحه کانتینر نشان می‌دهد تگ در حال حاضر به کدام نام میزبان اشاره می‌کند.
- سرویس‌دهی برقرار است اما سایت شما هنوز Tag Manager را از signalhost.io بارگذاری می‌کند: قطعه‌کد قدیمی هنوز روی صفحه است. آن را با قطعه‌کدی که در صفحه کانتینر هست جایگزین کنید.