ブログ

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

公開 2026年9月22日· 更新 2026年10月18日· 読了 6 分

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

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

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

タギングサーバーを一から用意する場合は、サーバーサイド Google Tag Manager の設定手順をご覧ください。

レコード

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 が設定されています。ホスト名が配信を始めると、当社はそれを独自ドメインに書き換えてコンテナを再公開します。ドメインを削除すればテナントホスト名に書き戻します。その瞬間から、ヒットは自社ドメインに送られます。

あなたに残された作業が 1 つあります。サイト上のスニペットは、依然として signalhost.io のアドレスから Tag Manager を読み込んでいます。それでも動作はしますが、フィルタリストがまだ一致させうる唯一のリクエストなので、置き換えてください。ドメインが配信を始めるとすぐにコンテナページに新しいスニペットが表示され、同時にメールでもお送りします。2 つ目を追加するのではなく、置き換えてください。スニペットが 2 つあると、コンテナが 2 回読み込まれます。

ドメインの削除は、その逆の手順です。ダッシュボードでドメインを削除し、そのときコンテナページに表示されるスニペットをサイトに戻し（再び signalhost.io のアドレスから読み込まれます）、DNS レコードは最後に削除してください。先にレコードを消すと、ダッシュボードが気づくまでの間、サイトはもはや解決しない名前からタグを読み込むことになります。

うまくいかないとき

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