Cloudflareを利用しているWordPressで「Error 1018」または「Error 1023」と「Could not find host」が表示されたら、Cloudflareが要求されたホストの情報を見つけられていません。
どちらも似たエラーですが、1018はHTTP 409、1023はHTTP 503で返ります。WordPressのテーマやプラグインを止める前に、エラー番号、完全なホスト名、Ray ID、発生時刻、Cloudflareのゾーン状態を確認します。
最初にエラー画面全体、完全なURL、Ray ID、発生時刻とタイムゾーンを保存してください。Cloudflareを有効化した直後なら短い反映待ちの場合がありますが、設定が誤っている状態を待ち続けても直りません。待つ条件と設定を直す条件を分けます。
先に結論：1018・1023は8段階で確認する
- Error 1018か1023か、Ray ID、時刻、URLを保存する
- 入力したホスト名の綴りとwww・サブドメインを確認する
- Cloudflareの対象アカウント、ゾーン、Zone statusを確認する
- Cloudflare追加・移管直後か、パートナー経由かを確認する
- 権威ネームサーバーと対象DNSレコードを照合する
- 別回線・別地域でも同じか一度だけ比較する
- Ray ID入り画面とHARを安全にそろえる
- ホスティング会社またはCloudflare Supportへ証拠を渡す
DNS名そのものを解決できない1001なら、Cloudflare Error 1001のDNS・CNAME確認手順を使います。530の本文に1016が表示される場合は、Cloudflare 530／1016のオリジンDNS確認手順へ進んでください。
Error 1018・1023とは？
Cloudflare公式のError 1018は、Cloudflareがホストを見つけられない状態です。公式は主な原因として、ドメインをCloudflareで有効化した直後に設定がエッジネットワークへ配布中であることと、ホスティング会社などCloudflareパートナー経由で作成されたドメインのDNS障害を挙げています。
Cloudflare公式のError 1023も、構成問題または反映遅延によってホストを見つけられない状態です。原因とSupportへ渡す情報がほぼ同じため、この記事では二つをまとめて確認します。
| 項目 | Error 1018 | Error 1023 |
|---|---|---|
| 画面の主題 | Could not find host | Could not find host |
| HTTP応答 | 409 | 503 |
| 代表原因 | 有効化直後の配布遅延、パートナーDNS障害 | 構成問題、配布遅延、パートナーDNS障害 |
| Supportへ渡すもの | ドメイン、Ray ID入り画面、HAR | ドメイン、Ray ID入り画面、HAR |
1001・1016・523・404との違い
| 表示 | 問題の場所 | 最初の確認 |
|---|---|---|
| 1018・1023 | Cloudflareが対象ホスト情報を見つけられない | ゾーン状態、反映、パートナー構成、Ray ID |
| 1001 | 要求ドメインのDNS解決 | 要求ホスト、CNAME、権威DNS |
| 530／1016 | Cloudflareがオリジン名を解決できない | オリジンA・AAAA・CNAME、Load Balancer |
| 523 | Cloudflareからオリジンへ到達できない | オリジンIP、経路、ファイアウォール |
| WordPressの404 | 到達後に該当ページが見つからない | パーマリンク、投稿状態、転送 |
ホストは見つかるもののオリジンへ到達できない場合は、Cloudflare 523の到達経路確認手順を使います。Cloudflare固有画面ではなくWordPressページの404なら、WordPressの404エラー確認手順でパーマリンクと公開状態を確認してください。
最初に完全なホスト名を確認する
エラーになったURLを、画面表示ではなくアドレスバーからコピーします。example.com、www.example.com、blog.example.comは別のホスト名です。メール、QRコード、ブックマーク、古い管理画面リンクに、存在しないサブドメインや似た綴りが含まれていないか確認します。
一つのホストだけ1018・1023で、ルートドメインや別サブドメインは正常なら、そのホストのCloudflare側登録やパートナー側構成を優先して調べます。すべてのホストで同時に起きるなら、ゾーン状態、ネームサーバー変更、アカウントやパートナー連携の影響が広い可能性があります。
CloudflareのZone statusを確認する
Cloudflareダッシュボードで正しいアカウントとドメインを選び、OverviewのZone statusを確認します。Activeなら通常利用できる状態です。Pending Nameserver Updateなら、Cloudflareは割り当てたネームサーバー上のDNS問い合わせへ応答しても、ゾーンはまだ有効化されておらず、Cloudflareへのプロキシには使えません。
Cloudflare公式のZone statusによると、Primary setupではレジストラ側のネームサーバーがCloudflare指定値と一致する必要があります。CNAME setupでは確認用TXTレコードなど、構成方式ごとの有効化条件を満たす必要があります。
有効化直後は短い反映待ちかを確認する
Cloudflare公式は、最近有効化したドメインの情報がグローバルネットワークへ配布されるまで数分かかる場合があると説明しています。直前にゾーンを追加・再有効化し、設定とネームサーバーが正しいなら、変更を増やさず短時間待って再確認します。
一方、Zone statusがPendingのまま、指定ネームサーバーが違う、DNSSECの古いDSレコードが残る、パートナー側でホストを登録できていない場合は、待つだけでは直りません。変更時刻、変更者、現在の状態を記録して原因設定を直します。
権威ネームサーバーとDNSレコードを照合する
レジストラで設定した権威ネームサーバーと、Cloudflareが対象ゾーンへ割り当てたネームサーバーを比較します。移管やアカウント変更の直後は、古いCloudflareゾーンのネームサーバー、別アカウントの割当値、ホスティング会社の既定ネームサーバーが残っていないか確認します。
dig NS example.com +short
dig A www.example.com +short
dig AAAA www.example.com +short
dig CNAME www.example.com +shortexample.comとwww.example.comは実際のドメイン・ホスト名へ置き換えます。A・AAAA・CNAMEのすべてが必要なわけではありません。現在の設計に必要なレコードだけが、正しい権威DNS上にあるかを確認します。
Cloudflare公式のDNS問題確認では、スペル、ルート・サブドメインの必要レコード、権威ネームサーバー、DNSSEC、負のキャッシュを分けて確認するよう案内しています。DNSレコードを削除して作り直す前に、どのDNSが権威を持っているかを確定してください。
パートナー経由のCloudflareか確認する
レンタルサーバーやホスティング会社の管理画面からCloudflareを有効化した場合、DNSレコードやCloudflareゾーンを直接Cloudflareダッシュボードではなく、パートナー側で管理する構成があります。Cloudflare公式も、パートナー経由で追加したドメインのDNS問題を1018・1023の代表原因に挙げています。
- Cloudflareをどの管理画面から有効化したか
- DNSレコードを編集する正式な場所はどこか
- ホスティング会社の契約・サイト紐付けが有効か
- 対象ドメインとWordPressサイトの関連付けが残っているか
- ホスティング会社側で障害・メンテナンスがないか
- 最近プラン変更、サーバー移転、アカウント変更をしていないか
パートナー管理のDNSをCloudflare側でも重複編集すると、どちらが正しい設定か分からなくなります。ホスティング会社の公式手順で管理場所を確認し、サポートへ連絡するときはCloudflareのRay IDと発生時刻も渡します。
Supportへ渡す証拠をそろえる
Cloudflare公式の1018・1023は、解決しない場合にドメイン名、Ray ID入りのエラー画面、再現時のHARをSupportへ渡すよう案内しています。ホスティング会社へ問い合わせる場合も、同じ情報が切り分けに役立ちます。
- Error 1018または1023が読める画面全体
- 画面に表示されたRay ID
- 発生時刻とタイムゾーン
- 失敗した完全なURLとホスト名
- Cloudflareのアカウント名、ゾーン名、Zone status
- Cloudflare追加・有効化・移管を行った時刻
- 現在の権威ネームサーバー
- ホスティング会社・パートナー名と管理画面
- 別回線・別地域での再現結果
- 機密情報を除去したHAR
HARにはCookie、Authorization、フォーム本文、個人情報などが含まれる場合があります。Cloudflare公式の情報収集手順に沿ってプライベートウィンドウで取得し、共有前に機密情報を除去します。SNSや公開フォーラムへそのまま添付しないでください。
原因別の安全な直し方
有効化直後の配布遅延だった場合
Zone status、ネームサーバー、対象ホストが正しく、直前にCloudflareを有効化した場合は、追加の変更をせず数分後に再確認します。再試行の時刻とRay IDを残し、複数地域で段階的に回復するかを見ます。ブラウザー更新を連打し続けないでください。
ゾーンがPending・Movedだった場合
レジストラのネームサーバーをCloudflare指定値へそろえ、古いDNS事業者の値を残さないようにします。DNSSECを以前のDNS事業者で使っていた場合は、古いDSレコードが有効化を妨げていないか確認します。変更はレジストラとCloudflareの両画面で記録し、反映完了まで設定を繰り返し変えません。
ホスト名・DNSレコードが不足していた場合
エラーになった正確なホストに必要なA、AAAA、CNAMEのいずれかを、権威を持つ管理画面へ追加・修正します。wwwの有無、サブドメイン名、CNAMEの最終参照先、Proxy statusを確認します。使っていないAAAAや古いCNAMEを根拠なく足さないでください。
パートナー側の構成不備だった場合
ホスティング会社の管理画面でCloudflare連携を再確認し、自分で修正できない場合は、ドメイン、ホスト名、契約・サイト識別情報、Ray ID、発生時刻、画面、HARをサポートへ渡します。Cloudflare Supportへ直接問い合わせるべきか、パートナーが取り次ぐ構成かも確認してください。
修正後の確認項目
- 1018・1023が消え、意図したWordPressページが表示される
- Zone statusがActiveになっている
- ルート、www、使用中サブドメインのDNSが正しい
- トップ、投稿、固定ページ、カテゴリー、検索、404が正常
- 管理画面のログイン、保存、プレビューが正常
- 画像、CSS、JavaScript、REST API、サイトマップが正常
- 別回線・別地域でも同じホストへ到達できる
- 1001、1016、523、1000へ変化していない
- 一時的に追加したテストレコードや迂回設定が残っていない
- 変更内容、担当者、復旧時刻、Support回答を記録した
DNS設定を直した後に「DNS points to prohibited IP」へ変わった場合は、Cloudflare Error 1000の確認手順で、Cloudflare IPやプロキシ循環を設定していないか確認します。
やってはいけない対処
- エラー番号とRay IDを保存せずDNSを変更する
- 1018と1023をWordPressの404として処理する
- Cloudflare有効化直後にゾーンを何度も削除・再作成する
- パートナー管理とCloudflare管理の両方で同じDNSを編集する
- 待てば直ると決め付け、Pendingや誤ったネームサーバーを放置する
- 古いDNSレコードを一括削除する
- Cloudflareの共有IPをオリジンとして登録する
- 機密情報を含むHARを公開場所へ添付する
- 無関係なテーマ、プラグイン、WordPressユーザーを削除する
まとめ
Cloudflare Error 1018・1023は、Cloudflareが要求されたホストを見つけられないエラーです。1018はHTTP 409、1023はHTTP 503ですが、有効化直後の反映待ちと、パートナー経由のDNS・構成問題という確認軸は共通します。
エラー画面、ホスト名、Ray ID、時刻、Zone status、権威ネームサーバー、HARを先にそろえ、待つべき反映遅延か、直すべき構成不備かを判断してください。WordPress本体を変更せず、ホスト情報が欠けた場所だけを直すことが安全な復旧です。