ブログ

独自ドメインをタギングサーバーに向ける：CNAME、証明書、そして Cloudflare のエラー 1014

公開 2026年9月22日· 読了 5 分

最初にお渡しするホスト名は、signalhost.io 配下のランダムなラベルです。それで動きますし、多くのサイトには十分です。すでに googletagmanager.com ではないのですから。しかし自社ドメインのサブドメインこそが、あらゆるフィルタリストとブラウザルールを生き延びる形です。ブラウザにとってそれは単にあなたのサイトだからです。そこへ至るには DNS レコード 1 つと数分で足ります。少し間違えると、あなたの側では何も説明できないエラーメッセージが出るので、失敗パターンも含めた手順の全体をここに記します。

なぜ自社サイトのサブドメインなのか

理由は 2 つあり、性質が異なります。広告ブロッカーにとって、リクエストはホスト名がリストに載っていればサードパーティです。signalhost.io は今日どのリストにも載っていませんが、明日は載るかもしれません。yoursite.com が載ることは決してありません。ブラウザにとって、metrics.yoursite.com からのレスポンスで設定された Cookie は yoursite.com のファーストパーティ Cookie であり、それに伴う長い有効期限を持ちます。一方、他のドメインからの Cookie は制限されるか拒否されます。タギングサーバーはどちらでも同じです。扱いを変えるのはホスト名です。

レコード

DNS プロバイダで、選んだサブドメインを当社の DNS のみのエンドポイントに向ける CNAME を 1 つ：

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

ランダムなテナントホスト名でも、ワイルドカードでもありません。tenants.signalhost.io はこの用途のために当社が公開している名前で、なぜこの名前でなければならないかは次のセクションで説明します。

自社ドメインが Cloudflare にある場合は、プロキシをオフ — グレーの雲、「DNS only」— にしてレコードを作成してください。プロキシ付きのレコードは訪問者のリクエストをあなたの Cloudflare アカウント経由で当社に届けることになり、後述の証明書のステップがそれを通しては完了できません。

Cloudflare のエラー 1014 と、なぜ向け先が DNS のみでなければならないか

当社のホスト名は Cloudflare の背後にあります。お客様が CNAME を当社のプロキシ付きの名前 — ワイルドカードやテナントホスト名 — に向けると、そのトラフィックは当社とは別の Cloudflare アカウントに属するホスト名として Cloudflare に到達します。Cloudflare はこれをエラー 1014「CNAME Cross-User Banned」で拒否します。表示されるページは Cloudflare のもので、どちらの名前も出てこず、あなたの DNS にもサイトにもブラウザにも、それを説明するものはありません。

tenants.signalhost.io は意図的にプロキシなしです。当社のサーバーへ直接解決するため、そこへの CNAME はそのまま動作します。ダッシュボードの DNS チェックはプロキシ付きの向け先を名前で検出して変更点を示しますが、最初から作らないほうが早いです。

証明書

レコードが解決すると、当社はあなたのホスト名の Let's Encrypt 証明書を申請します。検証は HTTP-01 です。Let's Encrypt がその名前のポート 80 に平文 HTTP で特定のパスを取得しに来て、当社がそれに応答します。平文 HTTP なのは、まだ証明書が存在しないから — 今まさに取得しているものだから — で、当社のエッジが応答する唯一の非暗号化パスがこれです。nonce の照合であり、この経路で他に到達できるものはありません。

数分を見込んでください。ダッシュボードには 3 つのステップが順に表示されます。CNAME が解決する、証明書が発行される、ホスト名が配信中になる。CNAME が緑なのに証明書のステップで止まる場合、ほぼ確実にあなた側のレコードがプロキシ付きです。Cloudflare が検証リクエストに自前の証明書とページで応答してしまい、Let's Encrypt は違うものを見ることになります。

配信が始まった後

ウェブコンテナの Google タグにはサーバーコンテナ URL が設定されており、ホスト名が配信を始めると当社はそれを独自ドメインに書き換えてコンテナを再公開します。ドメインを削除すればテナントホスト名に書き戻します。サイトのスニペットは変わりません。スニペットはコンテナを読み込み、コンテナが送信先を知っています。

だからこそ削除の順序が重要です。先にダッシュボードでドメインを削除し、それから DNS レコードを削除してください。先にレコードを消すと、ダッシュボードが気づくまでの間、コンテナは訪問者をもはや解決しない名前に向け続けます。

うまくいかないとき

ブラウザにエラー 1014：CNAME が当社のプロキシ付きの名前を指しています。向け先を tenants.signalhost.io に変更してください。
CNAME は緑、証明書が 15 分以上保留：あなたのレコードがプロキシ付きです。DNS プロバイダで雲をグレーにしてください。
CNAME が一向に緑にならない：同じ名前に競合する A または AAAA レコードがないか確認し（CNAME はそれらと共存できません）、伝播に最大 1 時間を見込んでください。
配信中なのにコンテナページに新しい名前からのトラフィックが出ない：ウェブコンテナがまだ再公開されていません。ホスト名の稼働から数分以内に行われます。コンテナページには、タグが現在どのホスト名を指しているかが表示されます。