速度改善・安全対策

WordPressでCloudflare Error 1034が出るときの直し方｜Edge IP・SaaS設定の確認順

Cloudflareを利用するWordPressで「Error 1034: Edge IP Restricted」が表示されたら、ドメインが使っているIPアドレスをCloudflareのエッジ検証が制限しています。

これはWordPressのテーマやプラグインが直接起こすエラーではありません。DNSレコードの接続先、Cloudflare for SaaSのカスタムホスト名登録、BYOIP・専用IPとCloudflareアカウントの関連付けを確認します。

エラー画面、完全なURL、Ray ID、発生時刻、DNS変更前の値を保存するまで、A・AAAA・CNAMEを削除しないでください。正しい接続先が分からないまま値を入れ替えると、1034が消えても別のDNS・SSL・到達エラーへ変わる可能性があります。

先に結論：Error 1034は8段階で確認する

  1. 1034の画面、Ray ID、URL、時刻とタイムゾーンを保存する
  2. 影響するホスト名とページ範囲を切り分ける
  3. Cloudflareで正しいアカウント・ゾーンを選ぶ
  4. DNSレコードのType、Name、Content、Proxy statusを保存する
  5. Contentに1.1.1.1や管理していないIPがないか確認する
  6. SaaS利用ならCNAME先とカスタムホスト名の状態を確認する
  7. BYOIP・専用IPなら利用権限、委任、Address Mapを担当者へ確認する
  8. 原因設定だけを直し、DNS・HTTPS・WordPress機能を再確認する

DNSレコードがCloudflare IPやプロキシ循環を指す1000なら、Cloudflare Error 1000の確認手順を使います。名前解決そのものが失敗する1001は、Cloudflare Error 1001のDNS・CNAME確認手順へ進んでください。

Cloudflare Error 1034とは？

Cloudflare公式のError 1034は、ドメインが使用するIPアドレスをEdge IP Validationが制限した状態です。Edge IP Validationは、BYOIPのIP範囲、専用・固定IP、特定顧客に関連付けられたIP空間が、無関係なCloudflareアカウントや未登録ホストから使われることを防ぎます。

公式が挙げる代表例は二つです。一つは、DNSレコードの仮IPとして以前から1.1.1.1を指定している構成です。もう一つは、Cloudflare for SaaSを使うサービスへ独自ドメインを接続したものの、そのホスト名が提供会社側で正しく登録・検証されていない構成です。

1000・1002・1014・1001との違い

許可された磁器の住所タイルと門の外で止まる藍色の球体
表示主な意味最初の確認
1034制限されたEdge IPとアカウント・ホストの関連が合わない1.1.1.1、SaaSホスト登録、BYOIP・専用IP権限
1000禁止IP、プロキシ循環、転送ヘッダー、SNI等実オリジン、DNS、プロキシ、ヘッダー
1002DNSが禁止・制限IPまたは誤ったCNAMEを指すA・CNAMEのContent、オリジンIP
1014別CloudflareアカウントのゾーンへCNAMEゾーン所有、SaaS Custom Hostname
1001要求ドメインのDNS解決失敗ホスト名、権威DNS、CNAME最終参照先

別アカウントのCloudflareゾーンへCNAMEした直後なら、Cloudflare Error 1014のCNAME・SaaS確認手順も比較してください。禁止・制限IPをDNSの接続先にした1002は、Cloudflare Error 1002の確認手順で切り分けます。

変更前に証拠と現在値を保存する

ホスト名とDNS接続先とSaaS所有確認に相当する磁器部品を検査する場面

1034を直す前に、どのホストが、どのDNS設定を通り、どのサービスへ接続する予定だったかを記録します。トップだけでなく、www、サブドメイン、管理画面、APIなど、同じゾーン内でもホストごとに結果が違うか確認してください。

  • Error 1034とEdge IP Restrictedが読める画面全体
  • Ray ID、発生時刻、タイムゾーン
  • 失敗した完全なURLとホスト名
  • Cloudflareのアカウント名とゾーン名
  • DNSレコードのType、Name、Content、Proxy status、TTL
  • 直前にDNS・SaaS・サーバーを変更した日時と担当者
  • 接続する予定のホスティング会社・SaaS名
  • SaaS提供会社から指定されたCNAME target
  • Custom Hostnameと証明書の状態
  • BYOIP・専用IP・固定IP契約の有無

DNSレコードのContentを確認する

Cloudflareダッシュボードで対象ゾーンのDNS Recordsを開き、エラーになったホストのA、AAAA、CNAMEを確認します。見るのは公開DNSの応答だけでなく、管理画面に保存されているContentです。プロキシ済みレコードを外部からdigするとCloudflareのAnycast IPが返るため、それだけで誤設定とは判断できません。

dig A example.com +short
dig AAAA example.com +short
dig CNAME www.example.com +short

コマンドのexample.comは実際のホスト名へ置き換えます。結果は経路確認に使いますが、オレンジ雲のレコードでは実オリジンIPを公開しないのが通常です。正しいオリジン値は、契約サーバーの管理画面・公式案内・移行記録とCloudflare DNSのContentを照合します。

Contentが1.1.1.1だった場合

Cloudflare公式は、ドメインを1.1.1.1へ向けていた構成は1034になると明記しています。通常のWordPressなら、ホスティング会社が指定する実オリジンIPまたは正式なCNAMEへ直します。1.1.1.1を別の適当なCloudflare IPへ置き換えてはいけません。

オリジンを持たない転送・Workers構成の場合

Redirect RulesやWorkersだけで処理し、接続先サーバーを持たない構成では、Cloudflare公式のoriginless setupの案内に従い、IPv4の192.0.2.0またはIPv6の100::を仮IPにできます。このDNSレコードはプロキシを有効にし、ルールが対象ホストへ正しく一致することも確認します。

ただし、実際にWordPressサーバーへ接続するサイトで仮IPを使うと、オリジンへ到達できません。通常のWordPressとoriginless構成を混同せず、現在の設計を確認してから変更してください。

Cloudflare for SaaSの登録状態を確認する

ブログサービス、会員サイト、予約システム、ホワイトラベル機能などへ独自ドメインを接続している場合、提供会社がCloudflare for SaaSを使っていることがあります。この構成では、利用者側のDNSだけでなく、提供会社側でそのホスト名をCustom Hostnameとして登録・検証する必要があります。

  1. SaaS提供会社が指定した正確なCNAME targetを確認する
  2. 対象ホスト名が提供会社側へ登録済みか確認する
  3. hostname statusがactiveか確認する
  4. ssl.statusがactiveか確認する
  5. DNSが現在のSaaS targetを指しているか確認する
  6. 別SaaSや旧契約のCNAMEが残っていないか確認する

Cloudflare公式のHostname validationでは、hostnameの所有確認と証明書確認は別の状態です。hostnameがactiveでも証明書がactiveとは限らず、DNSの接続先も合って初めて本番HTTPSの準備が整います。

利用者がSaaS提供会社のCloudflareアカウントを操作できない場合は、勝手に別のIPを試さず、ホスト名、現在のCNAME、1034画面、Ray ID、発生時刻を提供会社へ送ります。「DNSは合っているはず」だけでなく、Custom Hostnameの登録と検証状態を確認してもらってください。

BYOIP・専用・固定IPを利用している場合

BYOIPやCloudflareの専用・固定IPは、通常の共有Anycast IPとは管理方法が異なります。Cloudflare公式のBYOIPでは、IP prefixの所有確認、利用アカウント、Address Map、service bindingなどで、どのIPをどのサービス・ゾーンに使うかを管理します。

  • 問題のIPを所有・契約するCloudflareアカウント
  • 現在ゾーンが所属するアカウント
  • 別アカウントへのprefix delegationの有無
  • Address Mapのアカウント・ゾーン関連付け
  • IP address service bindingの対象サービス
  • 直前のアカウント移動、契約変更、委任変更
  • SaaS提供会社と自社のどちらがIPを管理するか

これらは契約・アカウント権限に関わるため、一般サイトのDNS画面だけで直せない場合があります。Cloudflareの契約担当者またはSaaS提供会社へ、IP、ゾーン、アカウント、変更日時をそろえて確認します。権限が不明なIPをAレコードへ入れて回避しないでください。

原因別の安全な直し方

正しい磁器の住所タイルが許可された開口部に収まり門が開いた場面

通常のWordPressが1.1.1.1を指していた

ホスティング会社へ正しいオリジンIPまたはCNAMEを確認し、対象ホストのContentだけを更新します。AとAAAAが同じ名前にある場合は両方を確認し、古いAAAAだけが別IPを指していないかも見ます。変更前後の値、担当者、時刻を保存します。

originless構成の仮IPが不適切だった

Redirect RulesやWorkersで完結することを確認し、公式の仮IP192.0.2.0または100::へ変更します。Proxy statusは有効にし、対象ルール、ホスト条件、リダイレクト先、HTTPSを確認します。WordPressオリジンが必要なホストには使いません。

SaaSのカスタムホスト登録が不足していた

提供会社の手順に従ってCustom Hostnameを登録・検証し、hostname status、ssl.status、DNS targetをそろえます。利用者側で完了できない場合は、提供会社に1034の証拠を渡します。検証完了前にCNAMEを何度も切り替えると、所有確認と証明書確認が遅れる場合があります。

BYOIP・専用IPのアカウント関連が違っていた

IPを管理するアカウント、ゾーン、委任、Address Map、service bindingを正しい契約状態へそろえます。変更範囲が他ゾーンへ影響する可能性があるため、担当者の確認なしにprefix全体やAddress Mapを削除しません。

修正後の確認項目

  • Error 1034が消え、意図したWordPressページが表示される
  • ルート、www、使用中サブドメインのDNSが設計どおり
  • トップ、投稿、固定ページ、カテゴリー、検索、404が正常
  • 管理画面のログイン、保存、プレビューが正常
  • 画像、CSS、JavaScript、REST API、サイトマップが正常
  • HTTPS証明書が対象ホストと一致する
  • SaaS利用時はhostname statusとssl.statusがactive
  • 1000、1001、1002、1014、1018・1023、523へ変化していない
  • 不要な1.1.1.1や古いCNAMEが残っていない
  • 変更内容、担当者、復旧時刻、提供会社の回答を記録した

修正後に「Could not find host」へ変わった場合は、Cloudflare Error 1018・1023のホスト確認手順で、ゾーン状態とホスト情報の反映を確認します。

やってはいけない対処

  • 証拠を保存せずA・AAAA・CNAMEを削除する
  • 1.1.1.1を別のCloudflare IPへ置き換える
  • 通常のWordPressへoriginless用の仮IPを設定する
  • プロキシ済みのdig結果だけでオリジンIP誤りと断定する
  • SaaS提供会社の指定と違うCNAMEを推測で試す
  • hostname statusだけ見てssl.statusを確認しない
  • 権限のないBYOIP・専用IPを別アカウントで使う
  • Address Mapやprefix委任を影響確認なしに削除する
  • 1034をWordPressプラグイン障害と決めつける
  • 機密情報を含む画面・ログを公開フォーラムへ載せる

よくある質問

Cloudflareのプロキシを一時的に外せば直りますか？

原因確認なしにDNS onlyへ変えることは勧めません。Cloudflareの防御やSaaS経路を外し、実オリジンIPを公開したり、別の証明書エラーへ変わったりする場合があります。まず現在のContentと接続設計を確認してください。

1.1.1.1は何に置き換えればよいですか？

通常のWordPressならホスティング会社が指定する実オリジンIPまたはCNAMEです。オリジンを持たない転送・Workers構成だけ、設計を確認したうえで公式の192.0.2.0または100::を使います。

SaaS側の設定は自分で直せますか？

利用者が操作できるのはDNSまでで、Custom Hostnameの登録や専用IPの利用権限は提供会社側にあることが多いです。CNAMEが指定どおりでも1034が続くなら、証拠を添えて提供会社へ登録・検証状態を確認します。

まとめ

Cloudflare Error 1034は、制限されたEdge IPと要求ホスト・Cloudflareアカウントの関連を確認できないときのエラーです。通常のWordPress、originless構成、Cloudflare for SaaS、BYOIP・専用IPでは、確認する管理者と正しい接続先が異なります。

1034の証拠とDNSの現在値を保存し、1.1.1.1、SaaSのCustom Hostname、BYOIP・専用IPの権限を分けて確認してください。推測で別IPへ迂回せず、正しいホストと接続先の関連だけを直すことが安全な復旧です。

-速度改善・安全対策