Cloudflareを使っているWordPressで「Error 1001: DNS resolution error」が表示されたら、WordPressのテーマやプラグインを触る前に、アクセスしたホスト名とDNS・CNAMEの参照先を確認します。
1001は、要求されたドメインを正しい宛先へ名前解決できず、Cloudflareがアクセスを処理できない状態です。WordPressのファイルやデータベースが壊れたことを直接示すエラーではありません。
最初にエラー画面、アクセスしたURL、発生時刻、Ray ID、直前に変更したDNSレコードを保存してください。現在設定を記録せずA・AAAA・CNAMEをまとめて変えると、原因が分からなくなるだけでなく、メールや外部サービスまで止めるおそれがあります。
先に結論：Error 1001は8段階で確認する
- エラー画面、URL、時刻、Ray ID、利用回線を保存する
- URLのドメイン・サブドメインに入力ミスがないか確認する
- 対象ホストにA・AAAA・CNAMEが存在するか確認する
- CNAMEの参照先が最終的に有効なIPへ解決するか確認する
- 現在の権威ネームサーバーとDNS管理場所を確認する
- 外部サービスが指定したCNAMEと登録済みホスト名を照合する
- 原因レコードだけを修正し、複数のDNS応答を比較する
- WordPressの公開ページ、管理画面、SSL、メールを再確認する
Cloudflare DNSがCloudflareの禁止IPを指す場合は、Cloudflare Error 1000の確認手順を使います。Cloudflareからオリジン名を解決できない場合は、Error 1016・530の確認手順で切り分けてください。
Cloudflare Error 1001とは？
Cloudflare公式のError 1001では、要求されたドメインへのアクセスを妨げるDNS解決失敗と説明しています。存在しないCloudflareドメインをCloudflare IPへ直接要求した場合や、CNAMEの参照先を解決できない場合などに発生します。
DNSは、example.comのような名前を接続先へ対応付ける仕組みです。WordPressが正常に稼働していても、名前から正しい宛先を見つけられなければ、閲覧者の要求はWordPressへ届きません。
1001・1000・1016・523・404の違い
| 表示 | 主な状態 | 最初に見る場所 |
|---|---|---|
| Cloudflare 1001 | 要求ドメインのDNS解決に失敗 | 要求ホスト、CNAME、権威DNS |
| Cloudflare 1000 | DNSがCloudflareの禁止IPなどを指す | A・AAAA・CNAME、プロキシ循環 |
| Cloudflare 1016・530 | Cloudflareがオリジン名を解決できない | オリジンA・AAAA、CNAME参照先 |
| Cloudflare 523 | 解決したオリジンへネットワーク到達できない | IP、経路、ルーティング |
| HTTP 404 | サーバーへ到達したが対象ページがない | URL、パーマリンク、転送 |
1001は「WordPressにページがない」という404より前の段階です。DNSが解決できなければ、WordPressのパーマリンク保存やキャッシュ削除をしても直りません。まず要求ホストとDNS応答を確認します。
原因1：存在しないホスト名やCloudflare IPへ直接アクセスしている
URLのタイプミス、削除済みサブドメイン、設定途中のテスト用ホストへアクセスすると、要求を処理する有効なドメインを特定できません。エラー画面からコピーしたURLでも、末尾のドット、全角文字、余分なサブドメインが混ざっていないか確認します。
Cloudflare公式は、Cloudflare IPアドレスをブラウザーで直接開くことを1001の原因として挙げています。Cloudflareの共有IPは一つのサイト専用ではないため、IPだけでは表示すべきホストを判断できません。動作確認でも、IPではなく正しいドメイン名でアクセスします。
原因2：CNAMEの参照先を解決できない
CNAMEは、あるホスト名を別の正規ホスト名へ対応付けます。Cloudflare公式のDNSレコード形式では、プロキシ対象のCNAMEは連続して別のCNAMEを参照できますが、最終的に有効なIPアドレスを持つAまたはAAAAへ到達する必要があります。
途中のCNAMEだけが存在していても、最終参照先が削除済み、期限切れ、入力ミス、DNS事業者の停止などで解決できなければ1001の候補になります。Cloudflare側のレコードだけでなく、外部サービス側の最終参照先まで確認してください。
外部サービスの指定値を省略しない
画像配信、フォーム、会員サービス、ホスティング、SaaSなどの独自ドメイン設定では、サービスが指定する完全なCNAME参照先と、サービス側へ登録した自分のホスト名を照合します。似たホスト名、古い環境、別アカウントの値を使わないでください。
原因3：Cloudflare外のドメインから不適切にCNAMEしている
Cloudflare公式は、Cloudflareを利用していない外部ドメインが、Cloudflareで有効なドメインへCNAMEしている構成を原因に挙げています。外部ドメインをCloudflareアカウントへ追加せず、表示したいサイトへ名前だけ向けても、正しいカスタムホストとして処理されない場合があります。
独自ドメインをSaaSや別サイトへ接続する場合は、CNAMEを作るだけでなく、接続先サービスでそのホスト名を登録・検証する手順が必要か確認します。別Cloudflareアカウント間のCNAME制限が表示される場合は、1001ではなくError 1014として扱います。
原因4：Cloudflare用の内部ホスト名を直接開いている
Cloudflare公式は、CNAMEセットアップで使われるwww.example.com.cdn.cloudflare.netのようなDNSレコードを直接開くことでも1001が起きると案内しています。この種の名前は、訪問者向けURLとして使うものではありません。
リンク、WordPressのサイトアドレス、リダイレクト、監視URL、外部サービスのコールバック先へ内部ホスト名を入れていないか確認します。閲覧者へ案内するのは、自分が所有し正しく設定した公開ドメインです。
原因5：Custom HostnameとAlways Onlineの組み合わせ
Cloudflare公式は、Cloudflare for SaaSのCustom HostnameでAlways Onlineが有効な場合も1001の原因として挙げ、該当構成ではAlways Onlineを無効にするよう案内しています。一般的なWordPress単独サイトのキャッシュ設定と混同しないでください。
Cloudflare for SaaSを利用していない場合は、この項目を推測で変更する必要はありません。SaaS提供者の管理画面や契約構成を確認し、自分が管理できない設定なら提供者へホスト名・Ray ID・時刻を渡します。
修正前に保存する情報
- エラー画面全体、Ray ID、発生時刻、タイムゾーン
- アクセスした完全なURLとHTTPメソッド
- 失敗するホスト名と成功するホスト名
- 対象ホストのA・AAAA・CNAME、Proxy status、TTL
- CNAME参照先を最後まで追った結果
- 現在の権威ネームサーバーとDNS管理事業者
- 直前に変更・削除・移行したDNSレコード
- 外部サービス側のカスタムドメイン登録・検証状態
DNSレコードには、メール、所有権確認、外部サービスが使う値も含まれます。修正前にレコード一覧を保存し、対象ホストと無関係なMX・TXT・DKIMなどを削除しないでください。
DNSとCNAMEを安全な順番で確認する
1. 正しいDNS管理場所を確認する
Cloudflare公式のDNSトラブルシューティングでは、ドメインがCloudflareのネームサーバーを使っているか確認するよう案内しています。レジストラ側の権威ネームサーバーが別事業者を指すなら、Cloudflare画面だけを変更しても公開DNSへ反映されません。
ホスティング会社経由でCloudflareへ追加したドメインは、DNSレコードをホスティング会社側で管理する場合があります。どの画面が正なのか分からないときは、ネームサーバーと契約形態を先に確認します。
2. 対象ホストのレコードを確認する
Cloudflare公式のDNS recordsで示されるType、Name、Content、TTL、Proxy statusを確認します。ルートドメイン、www、実際に利用するサブドメインは別々の名前です。成功する名前の設定を、考えずに別名へコピーしないでください。
3. CNAMEを最終参照先まで確認する
対象CNAMEのContentを確認し、その参照先がさらにCNAMEなら次も追います。最終的なA・AAAAが存在するか、参照途中でNXDOMAINや応答なしになっていないかを確認します。自分で管理しない参照先が停止している場合は、外部サービスへ連絡します。
4. 権威DNSと複数リゾルバーを比較する
権威ネームサーバーへ直接問い合わせた結果と、複数の公開DNSリゾルバーの応答を比較します。権威DNSでは新しい値、リゾルバーでは以前のNXDOMAINが返る場合、一般的なネガティブキャッシュの影響が考えられます。
Cloudflare公式は、新規レコードが一部で解決しない場合、以前の「存在しない」という応答がSOAのMINIMUM値に従ってキャッシュされることがあると説明しています。ローカルDNSキャッシュの消去だけで、上流リゾルバーのキャッシュまで消えるとは限りません。
安全な修正方法
- ホスティング会社または外部サービスの正しい指定値を確認する
- 現在のDNSレコード一覧と変更前の値を保存する
- 原因となる一つのName・Contentだけを修正する
- 権威DNSで意図した応答が返るか確認する
- 公開リゾルバーの反映を確認する
- 正しい公開ドメインからHTTPSでアクセスする
- 問題なければ監視・外部連携のURLも確認する
Proxy statusをProxiedからDNS onlyへ変えると、接続経路、公開IP、WAF、キャッシュ、SSLの扱いが変わります。「雲を灰色にすれば直る」と一律に変更せず、そのサービスがProxiedとDNS onlyのどちらを要求しているか公式手順で確認します。
やってはいけない対処
- Cloudflareの共有IPをAレコードや確認URLへ直接使う
- CNAMEセットアップ用の内部ホスト名を公開URLにする
- 原因を記録せずA・AAAA・CNAMEをまとめて変更する
- メール用MX・TXT・DKIMを無関係なのに削除する
- Proxy statusを理由なくDNS onlyへ変える
- 存在しない参照先を待つだけで、外部サービスの状態を確認しない
- DNS未解決なのにWordPress本体やパーマリンクを先に変更する
DNS変更は、正しい接続先を確認し、元へ戻せる状態にしてから一項目ずつ行ってください。推測したIPや古いCNAMEを入れると、1001が別の接続・SSLエラーへ変わるだけです。
修正後にWordPressで確認すること
- ルートドメイン、
www、利用中サブドメインが解決する - トップ、投稿、固定ページ、カテゴリー、検索、404が表示できる
- 正しいドメインへリダイレクトされ、無限転送がない
- HTTPS証明書が対象ホスト名で有効になっている
- 管理画面へログインし、記事を保存・プレビューできる
- 画像、CSS、JavaScript、サイトマップが取得できる
- フォーム、Webhook、REST API、外部サービスが動く
- メール送受信と認証用DNSレコードに影響がない
- 複数回線・複数リゾルバーで同じ宛先を返す
- 1001が1000、1014、1016、523、525、526へ変わっていない
Error 1001が直らないとき
正しいレコードが権威DNSから返るのに一部環境だけ失敗する場合は、発生回線、利用リゾルバー、残りTTL、時刻を比較します。Cloudflareの障害情報、外部DNS事業者、CNAME参照先サービスの状態も確認してください。
名前解決後に「Origin Is Unreachable」が出る場合は、Cloudflare 523の確認手順でIPと通信経路を調べます。サーバーへ到達した後にページだけ見つからない場合は、WordPressの404確認手順へ進みます。
Cloudflareまたは外部サービスへ問い合わせる場合は、Ray ID、時刻とタイムゾーン、対象ホスト、権威ネームサーバー、秘密情報を除いたDNSレコード、CNAMEを最後まで追った結果、直前変更をまとめます。
よくある質問
WordPressを再インストールすれば直りますか？
通常は直りません。1001はDNS名前解決の段階で発生するため、WordPressへ要求が届いていない可能性があります。先に要求ホストとDNS・CNAMEを確認します。
CloudflareのIPへ直接アクセスすれば確認できますか？
確認方法として適切ではありません。Cloudflare IPは複数ホストで共有され、公式にも直接IPアクセスは1001の原因として示されています。正しいドメイン名を使ってください。
DNSを直したらすぐ全員に反映されますか？
権威DNSで修正されても、以前の応答がリゾルバーへ残る場合があります。権威DNSと複数の公開リゾルバーを比較し、TTLやネガティブキャッシュを確認します。
まとめ
Cloudflare Error 1001は、要求されたドメインを正しい宛先へDNS解決できないときのエラーです。WordPress本体を先に変更せず、URL、Ray ID、時刻、DNSレコード、CNAME参照先を保存します。
正しいDNS管理場所を確認し、CNAMEを最終IPまで追い、原因レコードだけを修正してください。復旧後は公開ページだけでなく、管理画面、SSL、画像、REST API、外部連携、メールまで確認すれば、DNS修正による二次障害を防げます。