WordPressのドメインやサブドメインを外部サービスへCNAMEで接続したあと、「Error 1014: CNAME Cross-User Banned」と表示されることがあります。DNSレコードは保存できているのに、公開ページへアクセスするとCloudflareのエラー画面になる状態です。
Error 1014は、主に異なるCloudflareアカウントが管理する二つのゾーンを、通常のCNAMEで直接つないだときに起こります。WordPressのテーマやキャッシュの不具合ではなく、CNAME元と参照先の所有関係、Cloudflare for SaaSなどの製品構成が問題です。
1014を消すために、参照先のIPを推測してAレコードへ置き換えないでください。外部サービスでは接続先が変わることがあり、証明書やドメイン認証も壊れます。参照先の運営者に、正式なカスタムドメイン接続方法を確認します。
先に結論：Error 1014は7段階で確認する
- エラーURL、時刻、Ray ID、画面全体を保存する
- CNAME元と参照先の完全なホスト名を控える
- 両方がどのCloudflareアカウントで管理されているか確認する
- 参照先サービスの公式なカスタムドメイン手順を確認する
- 別アカウントならCloudflare for SaaSの設定を参照先所有者へ依頼する
- R2ならzone holdやアカウント状態も確認する
- 修正後にDNS、証明書、WordPress表示、再発の有無を確認する
CNAME先が単に存在しない、または名前解決できない場合は1014ではなく530／1016など別のエラーになります。参照先の名前解決から確認したい場合は、Cloudflare 530・Origin DNS Errorの安全な確認順を使ってください。
Cloudflare Error 1014とは？
Cloudflare公式のError 1014では、異なるCloudflareアカウントに属するドメイン間のCNAMEは標準では禁止されると説明されています。エラー名の「Cross-User」は、WordPressのユーザーではなくCloudflareアカウントの所有関係を指します。
同じドメイン内のCNAMEや、同じCloudflareアカウントが管理するゾーン間のCNAMEは認められます。一方、別の会社・制作会社・SaaS事業者が管理するCloudflareゾーンへ通常のCNAMEを向ける場合は、参照先がCloudflare for SaaSでカスタムホスト名として受け入れる構成が必要です。
つまり、DNSの反映速度よりも「誰がどちらのゾーンを管理しているか」「参照先が利用者のホスト名を正式に登録したか」が重要です。自分のCloudflare画面だけを何度見直しても、参照先側の登録がなければ解決できない場合があります。
1014・1000・1016の違い
| 表示 | 中心的な原因 | 最初に確認すること |
|---|---|---|
| Error 1014 | 別Cloudflareアカウント間のCNAME | 両ゾーンの所有アカウント、SaaS設定 |
| Error 1000 | 禁止IP、プロキシ循環、要求条件 | 実オリジンIP、転送経路、ヘッダー |
| 530／1016 | オリジン名を解決できない | A・AAAA・CNAMEと最終参照先 |
同じCNAME変更後に起こっても、1014は所有関係、1016は名前解決、1000は接続先や循環が中心です。Error 1000が表示されている場合は、Cloudflare Error 1000を直す確認順で実オリジンとプロキシ経路を確認してください。
WordPressでError 1014が出る主な原因
1．外部SaaSのCloudflareゾーンへ通常のCNAMEを向けた
会員サイト、予約、フォーム、画像配信、ヘッドレスCMSなどの外部サービスがCloudflareを利用しており、利用者のWordPressドメインからサービスの公開ホストへ直接CNAMEを作ったケースです。サービス側がそのホスト名をカスタムホストとして登録していなければ受け入れられません。
2．制作会社と運営会社でCloudflareアカウントが分かれている
ルートドメインは運営会社、接続先の別ドメインは制作会社など、管理者が分かれている場合があります。画面上のドメイン名が似ていても、別アカウントならCross-Userとして扱われます。招待されたメンバーが同じでも、ゾーンの所属先が違う場合があるため確認が必要です。
3．移行後も旧アカウントのゾーンを参照している
サイト移管や制作会社変更でCloudflareゾーンを新アカウントへ移した一方、CNAME先だけ旧アカウントに残ると、以前は同一アカウントだった接続が別アカウント扱いになることがあります。移行前後のゾーン所有者とDNS変更履歴を照合します。
4．Cloudflare for SaaSのカスタムホスト名が未登録
参照先がCloudflare for SaaSを導入していても、利用者のホスト名が登録・検証されていない場合があります。入力ミス、所有確認の失敗、証明書発行待ち、利用契約の未完了など、SaaS側の状態を確認します。
5．R2カスタムドメインの対象ゾーンにzone holdがある
Cloudflare R2のカスタムドメインを別アカウントのゾーンと組み合わせる場合、対象ゾーンのzone holdが接続を妨げることがあります。Cloudflare公式は、R2に関係する1014で対象ゾーンのzone holdを無効にする確認を案内しています。
6．R2側のアカウントが制限されている
フィッシング判定の確認中や未払いなどにより、R2を管理するアカウントが制限されている場合もあります。この状態は利用者側のWordPressやDNSを直しても解消できません。参照先アカウントの所有者がCloudflareの通知と請求状態を確認します。
7．サービスの案内と異なるホスト名へCNAMEを向けた
サービスが利用者ごとに専用のCNAME先を発行しているのに、案内ページや別顧客の公開ホストを参照しているケースです。見た目が似たホスト名でも受け入れ設定は異なります。契約画面に表示された接続先と一文字ずつ比較します。
変更前に保存する情報
- エラーが出る完全なURL、時刻、タイムゾーン、Ray ID
- CNAME元のホスト名、参照先の完全なホスト名
- レコードのプロキシ状態、TTL、変更日時
- CNAME元ゾーンが所属するCloudflareアカウント
- 参照先ゾーンの所有者・サービス名・管理アカウント
- 外部サービスが案内する正式なカスタムドメイン手順
- Cloudflare for SaaSまたはR2を使っているか
- 移行、アカウント変更、請求変更を行った日時
所有アカウントを共有するときは、アカウントIDの扱いを関係者と確認し、APIトークン、パスワード、請求情報を公開しないでください。切り分けにはゾーン名、所有会社、CNAME元・先、時刻があれば十分な場合が多いです。
最初にCNAMEの所有関係を確認する
CloudflareのDNS画面で対象CNAMEを開き、元のホストと参照先を控えます。次に、参照先を管理するサービスの契約画面や公式手順を確認し、その値が正式に発行されたものかを照合します。検索結果で見つけた一般的なホスト名へ置き換えないでください。
続いて、CNAME元と参照先が同じCloudflareアカウントに属するかを確認します。同じログインメールを使っていても、複数アカウントを切り替えて管理していることがあります。ダッシュボード上部のアカウント名と対象ゾーンを双方で確認します。
| 状況 | 判断 | 次の確認 |
|---|---|---|
| 同一ゾーン内 | 1014以外の設定不備を疑う | CNAME値、ルール、エラー発行元 |
| 同じアカウントの別ゾーン | 標準で許可される構成 | 所属アカウントを再確認 |
| 別アカウント間 | 通常CNAMEは1014の対象 | Cloudflare for SaaSの受け入れ設定 |
| R2カスタムドメイン | 固有条件がある | zone hold、アカウント制限 |
DNSの変更履歴がある場合は、サーバー移行の時系列も整理します。WordPressサーバー移行前後の確認手順に沿って旧・新サーバー、DNS、SSLの切替点を記録すると、どの時点で所有関係が変わったか追いやすくなります。
原因別の安全な直し方
1．参照先所有者にCloudflare for SaaSの設定を依頼する
別アカウントのサービスへ接続する正規の方法は、参照先の所有者が利用者のホスト名をCloudflare for SaaSのカスタムホスト名として登録することです。利用者側だけで完結する操作ではありません。サービスのサポートへ対象ホストと1014画面を送ります。
サービス指定のTXTレコードなどで所有確認が必要な場合は、現在のDNSを保存してから追加します。既存のメールやWeb用レコードを上書きせず、指定された名前・タイプ・値をそのまま登録してください。
2．同じアカウントで管理する予定なら所属を整理する
本来は同じ組織のゾーンなのに別アカウントへ分かれている場合は、関係者と管理方針を決めます。ゾーン移管はDNS、権限、請求、証明書へ影響するため、1014だけを理由にその場で移さず、変更計画とロールバック手順を用意します。
3．サービスが発行した正しいCNAME先へ戻す
参照先を取り違えていた場合は、契約画面またはサービス担当者が示す正式な値へ修正します。末尾のドット、サブドメイン、地域別ホスト、顧客ID部分を確認します。変更前の値と時刻を残し、反映後に名前解決を再確認します。
4．R2のzone holdとアカウント状態を確認する
R2カスタムドメインで1014が出る場合は、対象ゾーンの所有者がzone holdを確認します。アカウントが審査・制限状態ならCloudflareの通知、セキュリティ確認、未払い請求を確認し、必要に応じてアカウントチームへ連絡します。
5．証明書の発行・検証完了を待ってから公開確認する
カスタムホスト名の登録後、所有確認や証明書発行に時間がかかる場合があります。管理画面の状態が有効になる前に設定を繰り返し変更すると、検証がやり直しになることがあります。サービスの状態表示と案内時間を確認して待ちます。
やってはいけない対処
- CNAME先のIPを一般的なDNS検索で調べてAレコードへ固定する
- 1014をWordPressユーザー権限の問題だと思い込む
- 参照先所有者へ確認せずCloudflareアカウントを移管する
- 既存のTXT、MX、CNAMEをまとめて削除する
- 別顧客のカスタムホスト名や公開URLを参照先に使う
- 証明書検証中にレコードを何度も付け替える
- APIトークンやアカウントの認証情報を相手へ送る
- テーマ、プラグイン、WordPressデータベースを初期化する
外部サービスのIPは将来変更される可能性があり、CNAMEにはサービス側が接続先を管理できる利点があります。1014を避けるための一時的なIP固定は、後日突然つながらなくなる原因になります。
復旧後の確認項目
- CNAME元がサービス指定の参照先を返す
- CloudflareまたはSaaS画面でカスタムホスト名が有効
- トップ、投稿、固定ページ、対象サブドメインが開く
- 証明書が対象ホストに一致し、ブラウザ警告がない
- HTTPからHTTPS、www有無の転送が意図どおり
- WordPress管理画面と投稿保存が正常
- メールや他のサブドメインに影響がない
- 別回線と一定時間後の再確認でも1014が出ない
1014が消えて別のCloudflareエラーに変わった場合は、番号に応じて発生層を分けます。接続先が禁止IPならError 1000、名前を解決できないなら530／1016、IPは分かるが到達できないならCloudflare 523の確認手順です。
検索への影響と復旧後の対応
GoogleのHTTPステータス資料では、正常でない4xx・5xx応答が続くとクロールやインデックスへ影響し得ることが説明されています。1014画面だけで影響を決めず、レスポンスのHTTPステータスと継続時間を確認します。
復旧後はSearch Consoleで主要URLの最終クロール、ページのインデックス登録状態、サイトマップ取得を確認します。外部サービス用のサブドメインだけが対象なら、WordPress本体のURLまで一括で再送信する必要はありません。
それでも直らないときの問い合わせ情報
- CNAME元と参照先の完全なホスト名
- Error 1014の画面、Ray ID、時刻、タイムゾーン
- 両ゾーンの所有組織とCloudflareアカウントが同一か別か
- 利用している外部サービスと契約プラン
- カスタムホスト名の登録・検証状態
- R2、Cloudflare for SaaSの利用有無
- 直前の移行、DNS、アカウント、請求の変更
- 試した操作と結果
参照先が外部サービスなら、最初の問い合わせ先はそのサービス運営者です。利用者側のCloudflareサポートだけでは、別アカウントにあるカスタムホスト名の登録状態を変更できません。
よくある質問
プロキシをオフにすれば1014は消えますか？
一時的に表示が変わる場合はありますが、外部サービスがCloudflare経由とドメイン検証を前提にしていれば正式な解決ではありません。実オリジンの露出や証明書不整合も起こり得るため、サービス指定の接続方法を確認してください。
同じ会社のドメインなら問題ありませんか？
会社が同じかではなく、Cloudflare上でゾーンが所属するアカウントが同じかが基準です。同じ担当者がログインしていても、別アカウントを切り替えている場合があります。
WordPressの設定変更は必要ですか？
通常、1014の第一対処にWordPress変更は不要です。Cloudflareと参照先サービスの接続が復旧した後、WordPressだけに問題が残る場合に限り、バックアップを用意し、WordPress公式のデバッグ手順でログを確認します。
DNS反映待ちとの見分け方は？
Error 1014という番号が明示され、別CloudflareアカウントのホストをCNAME先にしているなら、単なる反映待ちより所有関係を優先して確認します。正規のSaaS設定完了後は、案内された反映時間を待って再確認します。
まとめ
Cloudflare Error 1014は、WordPressの利用者権限ではなく、CNAME元と参照先のCloudflareアカウントが異なるために起こる接続拒否です。別アカウント間をつなぐ場合は、参照先所有者によるCloudflare for SaaSの正規設定が基本になります。
CNAMEの元・先、所有アカウント、サービスの公式手順を保存し、参照先運営者と一項目ずつ確認してください。IP固定やレコード全削除で回避せず、所有確認と証明書まで含む正式なカスタムホスト名として復旧することが、再発を防ぐ近道です。