Cloudflareを利用しているWordPressで「Error 1000: DNS points to prohibited IP」と表示され、公開ページや管理画面へ入れなくなることがあります。DNS変更やサーバー移行だけでなく、リバースプロキシ、ロードバランサー、転送ヘッダーの設定変更後にも起こるエラーです。
Error 1000の中心的な原因は、Cloudflareが接続先として使えないIPアドレスをDNSが指していることです。特に、CloudflareのプロキシIPをオリジンサーバーのIPとして登録したり、別のプロキシから再びCloudflareへ要求を戻したりすると、正常な接続経路を作れません。
CloudflareのIP一覧から適当な値を選び、Aレコードへ入れないでください。必要なのはCloudflareのIPではなく、契約中のホスティング会社が案内する実際のオリジンIPです。変更前の値、エラー画面、時刻を保存し、一項目ずつ確認します。
先に結論：Error 1000は8段階で確認する
- エラーURL、時刻、Ray ID、画面全体を保存する
- 対象ホストと直前に変更したDNS・プロキシ設定を特定する
- Cloudflare DNSのA・AAAA・CNAME現在値を控える
- ホスティング会社の管理画面で正しいオリジンIPを確認する
- Cloudflare IPや別のプロキシを接続先にしていないか調べる
- X-Forwarded-Forなどの転送ヘッダーとSNIを確認する
- 原因箇所だけを修正し、設定の反映を待つ
- 公開ページ、管理画面、SSL、メール、再発の有無を確認する
名前をIPへ解決できない530／1016とは違い、Error 1000では「解決された接続先や要求の条件が許可されない」ことが問題になります。オリジン名そのものを解決できない場合は、Cloudflareの530・Origin DNS Errorを直す確認順を先に使ってください。
Cloudflare Error 1000とは？
Cloudflare公式のError 1000では、このエラーを「DNS record points to prohibited IP」と説明しています。Cloudflare DNSのAレコードがCloudflareのIPを指す場合や、リバースプロキシが要求をCloudflareへ戻す場合などが代表例です。
Cloudflareは閲覧者からの要求を受け、DNSに設定されたオリジンへ接続します。そのオリジンとしてCloudflare自身のプロキシIPが指定されると、接続がCloudflareへ戻り、正しいWordPressサーバーへ進めません。ループや不正な接続を避けるため、Error 1000として停止します。
この段階ではWordPressのPHP、テーマ、プラグインまで要求が届いていない場合が多く、WordPressを再インストールしても直りません。最初に見る場所はCloudflare DNS、オリジン情報、途中のリバースプロキシです。
1000・523・530／1016の違い
| 表示 | 問題が起きる段階 | 最初に見る場所 |
|---|---|---|
| Error 1000 | 解決されたIPや要求条件が禁止・不正 | オリジンIP、プロキシループ、ヘッダー、SNI |
| Cloudflare 523 | オリジンIPは分かるが到達できない | DNSのIP、通信経路、ファイアウォール |
| 530／1016 | オリジン名をDNSで解決できない | A・AAAA・CNAME、参照先ホスト名 |
同じDNS変更後でも対処先は異なります。523ならWordPressの523エラーを直す確認順、名前解決失敗なら530／1016、禁止IPや循環なら本記事のError 1000です。画面の番号と本文を保存してから分岐します。
WordPressでError 1000が出る主な原因
1．AレコードがCloudflareのIPを指している
CloudflareのDNSレコードに、実際のレンタルサーバーIPではなくCloudflareのエッジIPが登録されています。移行資料とCloudflare IP一覧を取り違えた場合や、名前解決結果をそのままオリジンIPだと思って登録した場合に起こります。
プロキシが有効な公開ドメインを調べると、CloudflareのIPが返るのは正常です。しかし、それは閲覧者が接続するCloudflare側の住所であり、Cloudflareが背後で接続するWordPressサーバーの住所ではありません。役割を混同しないことが重要です。
2．Load Balancerのオリジンがプロキシ済みレコードを指す
Cloudflare Load Balancingのオリジンとして、同じCloudflareゾーンのプロキシ済みホスト名を登録すると、CloudflareからCloudflareへ戻る構成になることがあります。オリジン専用ホスト名や実IPなど、製品仕様に合う接続先を使う必要があります。
3．別のリバースプロキシがCloudflareへ要求を戻す
Nginxの`proxy_pass`、外部CDN、ホスティング会社のプロキシ、コンテナのゲートウェイなどが、公開ドメインへ要求を転送しているケースです。公開ドメインは再びCloudflareを通るため、同じ経路を循環します。転送先には内部で到達できる実オリジンを指定します。
4．X-Forwarded-Forが異常に長い、または重複している
複数のプロキシが`X-Forwarded-For`へ値を追加し続けると、ヘッダーが100文字を超えたり、同名ヘッダーが二つ付いたりすることがあります。Cloudflare公式では、これらもError 1000の原因として挙げています。上限だけを広げるのではなく、どの機器が追加しているかを確認します。
5．CF-Connecting-IPを送信側が付けている
`CF-Connecting-IP`はCloudflareがオリジンへ転送するときに使うヘッダーです。閲覧者側やCloudflareより前段のプロキシが任意に付けると、正規の要求として扱えません。独自スクリプト、外形監視、APIクライアント、プロキシ設定で付加していないか確認します。
6．SNIと接続先ホストが一致していない
TLS接続で送られるSNIが、オリジン側で受け付けるホスト名と一致していない場合もあります。共用サーバーや複数ドメインを同じIPで運用していると、接続先IPだけ正しくても、想定と異なる仮想ホストへ届くことがあります。
7．外部SaaS側のカスタムホスト名が未設定
接続先のSaaS事業者がCloudflare for SaaSと独自IP構成を利用している場合、利用者のカスタムホスト名が事業者側で正しく登録されていないと、事業者のCloudflareアカウントからError 1000が返ることがあります。この場合は利用者側のWordPressを変更せず、事業者へ確認します。
変更前に必ず保存する情報
- エラーが出る完全なURL、対象ホスト名
- Error 1000の画面全体、Ray ID、発生時刻とタイムゾーン
- 常時か断続か、特定回線・端末・URLだけか
- Cloudflare DNSのA・AAAA・CNAME現在値とプロキシ状態
- ホスティング会社が案内する現在のオリジンIP
- Load Balancer、Origin Rules、リバースプロキシの転送先
- 直前に行った移行、DNS、SSL、CDN、WAFの変更
- 共有用資料から認証情報を隠したこと
設定画面を保存するときは、APIトークン、パスワード、Tunnelトークン、秘密鍵を写さないでください。サポートへ送る場合も、対象ホスト、時刻、Ray ID、必要なDNS値だけで切り分けを始められます。
最初に発生層を特定する
まず、Cloudflare DNSに保存された値と、ホスティング会社の管理画面に表示されるオリジン情報を横に並べます。公開ドメインを一般的なDNS検索で調べた結果だけでは、プロキシ有効時にCloudflare IPが返るため、実オリジンの確認にはなりません。
| 確認対象 | 正常な考え方 | 異常の例 |
|---|---|---|
| Cloudflare DNS | 契約中のオリジンIPまたは正式なCNAME | Cloudflare IP、旧IP、推測値 |
| Load Balancer | 直接到達できるオリジン | 同じプロキシ済み公開ホスト |
| リバースプロキシ | 内部または実オリジンへ転送 | 公開URLへ戻して循環 |
| 転送ヘッダー | 一貫した一つの連鎖 | 重複、異常な長さ、偽装 |
| TLS・SNI | 接続先の仮想ホストと一致 | 別ドメインのSNI |
レスポンスヘッダーを確認できる場合は、Cloudflareの診断ヘッダー資料も使います。画面情報とヘッダーを同じ時刻で残すと、ホスティング会社やSaaS事業者へ問い合わせる際に対象を示しやすくなります。
ヘッダー異常が疑われる場合は、WordPressの431・ヘッダー過大を直す確認順も参考になります。ただしError 1000では、単純な容量問題だけでなく、Cloudflareが予約するヘッダーを送信側が付けている可能性まで確認します。
原因別の安全な直し方
1．ホスティング会社の正式なオリジンIPへ直す
サーバー契約画面、移行完了メール、ホスティング会社のサポートで、現在のWebサーバーIPを確認します。Cloudflare DNSの対象Aレコードと比較し、違う場合だけ正しい値へ修正します。以前の値と変更時刻を控え、戻せる状態にします。
オリジンIPが分からないときは推測せず、ホスティング会社へ「Cloudflareが接続すべきWebサーバーのIPv4／IPv6」を確認してください。ネームサーバーやメールサーバーのIPとは限りません。
2．プロキシループを一か所ずつ解消する
外部リバースプロキシやNginxが公開URLへ転送している場合は、接続先を実オリジンまたは内部サービスへ変更します。目的がURL転送なら、サーバー間の代理接続ではなくHTTPリダイレクトが適切な場合もあります。構成の管理者と目的を確認して選びます。
Load Balancer、Origin Rules、外部CDNを併用している場合は、入口から実オリジンまでを一段ずつ書き出します。複数の設定を同時に無効化せず、どの段で公開ドメインへ戻っているかを特定して、その段だけを直します。
3．転送ヘッダーの生成元を一つに整理する
`X-Forwarded-For`が二重に付く場合は、前段のロードバランサーと後段のWebサーバーの両方が新規ヘッダーを作っていないか確認します。既存値への追加と上書きの役割を整理し、信頼するプロキシだけが扱うようにします。
`CF-Connecting-IP`をクライアントや独自プロキシが送っている場合は、その付加設定を削除します。Cloudflareがオリジンへ渡す値として扱い、外部から自由に指定させないことが重要です。
4．SNIとオリジンのホスト名を一致させる
共用サーバーや複数ドメイン構成では、Cloudflareがオリジンへ送るホスト名と、証明書・仮想ホストが受け付ける名前を一致させます。SNIやTLSの問題が疑われる場合は、Cloudflare 525とSNI・TLSを確認する手順で接続層を分けてください。
5．外部SaaSの運営者へ必要情報を渡す
自分が管理していないSaaSのホストをCNAME先にしている場合は、サービス運営者へ対象ホスト、エラー画面、発生時刻、Ray IDを送ります。利用者側でAレコードを勝手に別IPへ変えると、ドメイン検証や証明書発行まで壊れる可能性があります。
やってはいけない対処
- Cloudflareの公開IP一覧から選んだ値をAレコードへ入れる
- エラー画面を保存せずDNSレコードを全削除する
- プロキシ有効の公開ドメインを実オリジンだと思い込む
- 複数のCDN、Load Balancer、Origin Rulesを同時に変更する
- WAFやCloudflare全体を長時間無効にする
- ヘッダー上限だけを広げて重複の生成元を放置する
- APIトークンや認証情報を画面共有・公開掲示板へ載せる
- WordPress再インストールやDB初期化から始める
特にDNSの全削除は、Webだけでなくメール、サブドメイン、ドメイン所有確認へ影響します。対象ホストと原因項目が分からない状態では変更せず、ホスティング会社か構成管理者へ現在値を添えて確認してください。
復旧後の確認項目
- トップページ、投稿、固定ページが通常回線と別回線で開く
- `/wp-admin/`へログインでき、保存や画像アップロードができる
- HTTPからHTTPS、www有無の転送が一往復で完了する
- 証明書の対象ホスト、期限、警告表示に問題がない
- 問い合わせフォーム、REST API、外部連携が動く
- メール用DNSレコードが変更前と一致している
- Cloudflareやオリジンのログで循環アクセスが増えていない
- 一定時間後もError 1000が再発しない
転送が増えた場合は、WordPressのリダイレクトループを直す確認順でHTTPS、www、Cloudflare、WordPressの転送担当を整理します。Error 1000が消えても、同じ構成変更から別の循環が残ることがあります。
検索への影響と復旧後の対応
GoogleのHTTPステータス資料では、4xxや5xxの応答がクロールやインデックスに影響することが説明されています。Error 1000の画面だけで影響を断定せず、実際のHTTPステータスと発生期間を確認します。
短時間で復旧した場合は、まず主要URLの正常応答を確認します。長時間続いた場合は、Search Consoleのページインデックス、クロール統計、主要記事のURL検査を順に確認してください。大量のURL検査を一度に繰り返すより、重要ページから状態を確認します。
それでも直らないときの問い合わせ情報
- 対象ドメインとエラーになる完全なURL
- Error 1000の画面、Ray ID、発生時刻とタイムゾーン
- Cloudflare DNSの対象レコードとプロキシ状態
- ホスティング会社が案内するオリジンIP
- Load Balancer、リバースプロキシ、外部SaaSの有無
- 直前の変更内容と、すでに試した操作
- 常時か断続か、再現する回線や地域
- 認証情報を除いた関連ログ
Cloudflareへ問い合わせる前に、オリジンIPが正しいかをホスティング会社へ確認できると切り分けが早くなります。外部SaaSが発行元なら、そのサービス運営者のCloudflare構成で修正が必要な場合があります。
よくある質問
Cloudflareのプロキシをオフにすれば直りますか？
原因確認の一時試験になる場合はありますが、恒久対策ではありません。オフにすると実オリジンIPが公開され、防御やキャッシュも変わります。まず現在値を保存し、正しいオリジンIPと循環箇所を特定してください。
DNSの反映を待てば自然に直りますか？
正しい値へ変更済みなら反映待ちの時間は必要です。しかし、Cloudflare IPや循環するホスト名を設定したままでは待っても直りません。保存された値と権威DNSの応答を確認します。
WordPressのプラグイン停止は必要ですか？
Error 1000の第一確認では不要です。DNS・プロキシ層を直してもWordPressだけで問題が続く場合に限り、バックアップまたはテスト環境を用意し、WordPress公式のデバッグ手順でログを確認します。
自分ではどこまで作業できますか？
エラー情報の保存、Cloudflare DNSの現在値確認、ホスティング会社のオリジンIPとの比較までは行えます。Load Balancer、Nginx、SNI、ヘッダー設定を理解できない場合は、値を変えずにサーバー管理者へ渡す方が安全です。
まとめ
Cloudflare Error 1000は、WordPress本体より手前で、接続先IP、プロキシ経路、転送ヘッダー、SNIのいずれかが許可条件に合わないときに起こります。CloudflareのIPをオリジンへ設定せず、契約先が示す実オリジンを確認することが第一です。
エラー画面と現在値を保存し、オリジンIP、プロキシループ、ヘッダー、SNIの順で一項目ずつ確認してください。複数設定の同時変更を避ければ、復旧理由を説明でき、同じ構成ミスの再発も防ぎやすくなります。