速度改善・安全対策

WordPressでCloudflare Error 1003が出るときの直し方｜IP直接アクセス・URLの確認順

Cloudflareを利用しているWordPressで「Error 1003: Direct IP Access Not Allowed」が表示されたら、まずアドレスバーや監視設定にドメイン名ではなくIPアドレスが入っていないかを確認してください。

1003は、WordPressのテーマやプラグインが壊れたと決めつけるエラーではありません。Cloudflare公式は、クライアントやブラウザがCloudflare IPへ直接アクセスしたことを主因とし、URLにはWebサイトのドメイン名を使うよう案内しています。

Cloudflare IPを許可リストへ追加したり、DNSへ書き戻したりする前に、失敗した完全なURLとアクセス元を保存してください。原因がブックマークや監視URLなら、CloudflareやWordPressの設定変更は不要です。

先に結論：Error 1003は7段階で確認する

  1. 1003の画面、完全なURL、Ray ID、発生時刻を保存する
  2. IPを直接開いたのか、ドメインを開いたのかを確認する
  3. ブラウザだけか、監視・Webhook・APIだけかを切り分ける
  4. 正規のHTTPSドメインURLで表示できるか確認する
  5. IP形式のブックマーク、リンク、監視URL、連携先を探す
  6. 原因となるURLだけを正規ドメインへ置き換える
  7. PC・スマホ・外部連携とWordPress機能を再確認する

DNSのContent自体が禁止IPを指しているなら、Cloudflare Error 1002のDNS確認手順を使います。HTTPSで指定したホスト名とSNIが一致しない場合は、Cloudflare Error 1013のSNI・Host確認手順へ進んでください。

Cloudflare Error 1003とは？

Cloudflare公式のError 1003では、Cloudflare IPアドレスへの直接アクセスは許可されないと説明されています。主な原因は、クライアントまたはブラウザがCloudflare IPへ直接アクセスしたこと。解決策は、そのIPではなくWebサイトのドメイン名をURLに使うことです。

たとえば、通常の入口が https://example.com/ なのに、公開DNSの確認で見えたIPを使って https://203.0.113.10/ のように開く状態です。実際のCloudflare IPは例示用IPへ置き換えていますが、問題の考え方は同じです。

Cloudflareは多数のWebサイトを同じネットワークで配信します。要求されたドメイン名がなければ、どのWebサイトとして処理すべきか決められません。そのため、IPだけを入口にするのではなく、契約・DNS・証明書・WordPress URLに対応するドメイン名でアクセスします。

公開DNSでCloudflare IPが返ることとは別

CloudflareでProxy statusがProxiedのA・AAAA・CNAMEは、公開DNSへ問い合わせるとCloudflareのAnycast IPを返します。これは訪問者の通信をCloudflareへ通し、実オリジンを隠す通常動作です。

重要なのは、DNSが裏側でCloudflare IPへ名前解決することと、利用者がIPアドレスそのものをURLとして開くことは別だという点です。

操作例判断
ドメイン名でアクセスhttps://example.com/通常の入口
公開DNSを確認ドメインからCloudflare IPが返るProxiedなら通常
IPをURLとして直接開くhttps://203.0.113.10/1003の主因
DNS ContentへCloudflare IPを入力Aレコードの接続先にCloudflare IP1000・1002の原因になり得る

公開DNSで見えたCloudflare IPをブックマーク、監視URL、Aレコードへコピーしないでください。正しい入口はドメインURL、正しいオリジンはホスティング会社が示すIPまたは正式なCNAMEです。

1002・1013・404・403との違い

名札のない丸石が竹の門前で止まり編み札のある入口が開いている場面
表示問題の中心最初の確認
1003Cloudflare IPをURLとして直接開いた完全なURL、アクセス元
1002DNS Contentが禁止・制限IPを指すA・AAAA・CNAME
1013HTTP HostとTLS SNIが一致しないHTTPS要求のホスト名
404到達したサイト内にページがないパーマリンク、転送、ページ有無
403WAF・権限・サーバーがアクセスを拒否拒否元、ルール、権限

ドメインURLでWordPressへ到達するもののページがない場合は、WordPressの404エラー確認手順を使います。ドメインで開いて403になる場合は、WordPressの403 Forbidden確認手順でWAFや権限を切り分けてください。

変更前にアクセス元と完全なURLを保存する

竹の検査台にアクセス元を表す小物と丸石と編み札が並ぶ場面

1003は、ブラウザでは正常なのに監視サービスだけ失敗することがあります。逆に、古いブックマークからだけ1003になり、検索結果やトップページからは正常に見えることもあります。設定を変える前に、誰がどのURLを開いたかをそろえます。

  • Error 1003の文言が読める画面全体
  • アドレスバーを含む完全なURL
  • Ray ID、発生時刻、タイムゾーン
  • PC・スマホ・監視・Webhook・APIなどのアクセス元
  • クリック前のページ、メール、ブックマーク、アプリ
  • 正規URLとして運用しているドメインとHTTPS有無
  • ルート、www、サブドメインのうち影響する範囲
  • 直前に行ったサーバー移行、DNS変更、監視設定変更
  • 同じURLを別回線・別端末で開いた結果
  • 外部サービスに保存されている接続先URL

まず正規ドメインURLで表示を確認する

自サイトの正式なURLを、アドレスバーへ手入力します。WordPress一般設定の「WordPress アドレス」と「サイトアドレス」、Cloudflare DNSに登録したホスト、公開に使うHTTPS証明書のホスト名が一致しているか確認してください。

https://example.com/
https://www.example.com/

example.comは自分のドメインへ置き換えます。wwwあり・なしの両方を使うなら、一方を正規URLへ301リダイレクトする設計にし、どちらもIPアドレスへ転送しないことを確認します。

正規ドメインでは正常で、IPを開いたときだけ1003になるなら、CloudflareやWordPressを「IPでも表示できるようにする」必要はありません。IP形式URLを使っているアクセス元を直すのが安全です。

IP形式URLが保存されやすい場所

ブラウザのブックマークと履歴

移行作業中にIPで表示確認し、そのままブックマークしたケースです。アドレスバーの候補も古いIPを補完することがあります。ブックマークを削除または正規ドメインへ編集し、履歴候補ではなくドメインを手入力して確認します。

WordPress本文・メニュー・ボタン・画像リンク

投稿本文、固定ページ、カスタムHTML、メニュー、ウィジェット、テーマ設定へ絶対URLが保存されている場合があります。サイト内検索やデータベース置換を行う前にバックアップを取り、対象IPと置換範囲を確認します。シリアライズされたデータを単純な文字列置換で壊さないよう、WordPress対応の移行手段を使ってください。

死活監視・外形監視

監視先にCloudflare IPを指定すると、サイト名のない要求になり1003を記録することがあります。監視URLは正規のHTTPSドメインにし、必要なら期待するHTTPステータス、レスポンス本文、証明書期限も同じホスト名で確認します。

Webhook・API・決済・フォーム通知

外部サービスのコールバックURL、Webhook endpoint、API base URLにIPが残ることがあります。正規ドメインへ直す前に、送信元IP制限、署名検証、秘密情報、再送設定を保存します。URL変更後は本番データではなく、サービスが用意するテスト送信でHTTP結果とWordPress側の受信ログを確認します。

リダイレクト・短縮URL・メール

Cloudflare Redirect Rules、WordPressのリダイレクトプラグイン、Webサーバー設定、短縮URL、メールテンプレートがIPへ誘導していないか確認します。入口のリンクがドメインでも、途中の301・302のLocationがIPなら最終的に1003へ到達します。

開発・移行中にオリジンへ直接つなぐ場合

サーバー移行前の確認では、オリジンIPへ接続しながら本来のドメイン名を送る必要があります。ブラウザでIPを直接開くだけでは、Cloudflare 1003、証明書不一致、別サイト表示などが混ざり、正しい検証になりません。

技術担当者がコマンドで確認するなら、接続先IPだけを一時的に指定し、URLのホスト名は正規ドメインのままにします。Cloudflare公式のトラブル情報収集ガイドにも、curlの--connect-toを使ってオリジンへ接続する例があります。

curl -svo /dev/null https://example.com/ --connect-to ::203.0.113.34

example.comは正規ドメイン、203.0.113.34はホスティング会社が確認した実オリジンIPへ置き換えます。共有サーバーやWAFでは直接接続が許可されない場合があるため、提供会社の手順を優先してください。Cloudflare IPをオリジンIPとして指定する操作ではありません。

原因別の安全な直し方

編み札のある竹の入口が開き丸石が接続先から外された場面

アドレスバー・ブックマークがIPだった

正規のHTTPSドメインを開き、正常表示を確認してからブックマークを置き換えます。IPで管理画面へ入っていた場合も、https://example.com/wp-admin/のようにドメインを使います。ログイン画面へ転送される先もIPになっていないか確認してください。

サイト内リンクやリダイレクトがIPだった

発見したリンクと転送元を一覧にし、原因箇所だけを正規ドメインへ変更します。WordPress全体を一括置換する場合は、データベースとファイルのバックアップ、ステージング検証、置換対象の件数確認を行います。変更後はキャッシュを必要な範囲だけ削除します。

監視・Webhook・APIがIPだった

接続先を正規のHTTPSドメインへ変更し、認証ヘッダー、署名、送信元制限、タイムアウトは維持します。テスト送信で2xx応答だけでなく、WordPress側で意図した処理が一度だけ実行されたか確認します。決済や在庫連携では重複実行を避けるため、むやみに再送しません。

ドメインURLでも1003に見える

リンクをクリックした直後のURLだけでなく、最終URLとリダイレクト履歴を確認します。途中でIPへ転送されていれば、そのLocationを生成しているCloudflare Rule、WordPressプラグイン、Webサーバー設定、外部短縮URLを直します。最終URLにもドメインが残るなら、画面のエラー番号とRay IDを再確認し、1002・1013・403など別エラーを混同していないか切り分けます。

修正後の確認項目

  • 正規のHTTPSドメインでError 1003が消える
  • アドレスバーと最終リダイレクト先にIPが出ない
  • ルート、www、使用中サブドメインが正しいURLへ統一される
  • トップ、投稿、固定ページ、カテゴリー、検索、404が正常
  • 管理画面のログイン、保存、プレビューが正常
  • 画像、CSS、JavaScript、REST API、サイトマップが正常
  • ブックマーク、メニュー、ボタン、メール内リンクが正しい
  • 監視サービスが正規ドメインで正常判定する
  • Webhook・APIのテスト送信が一度だけ成功する
  • 1002、1013、403、404へ変化していない
  • 変更前後のURL、担当者、復旧時刻を記録した

原因が1003だけでなくDNS、プロキシ循環、転送ヘッダーまで広がる場合は、Cloudflare Error 1000の総合確認手順で切り分け直してください。

やってはいけない対処

  • Cloudflare IPでもサイトを表示できるよう無理に設定する
  • 公開DNSで見えたCloudflare IPをAレコードへ入力する
  • Cloudflare IPをWordPressのサイトURLへ設定する
  • 原因を保存せずDNSレコードやRedirect Rulesを削除する
  • 1003を消すためだけにCloudflareを一時停止する
  • すべてのProxiedレコードをDNS onlyへ変える
  • 外部サービスの認証・署名を確認せずURLだけ変える
  • 決済・Webhookを本番データで何度も再送する
  • IPアクセスの問題をテーマ・プラグイン障害と決めつける
  • エラー画面のRay IDや発生時刻を残さない

よくある質問

CloudflareのIPへ直接アクセスできないのは異常ですか？

異常とは限りません。Cloudflare公式は、Cloudflare IPへの直接アクセスを許可せず、Webサイトのドメイン名をURLに使うよう案内しています。通常の閲覧、監視、Webhookも正規ドメインを使います。

公開DNSでCloudflare IPが返るのは1003の原因ですか？

Proxiedレコードなら、公開DNSがCloudflare Anycast IPを返すのは通常です。1003の主因は、そのIPをURLとして直接開くことです。DNS応答を見ただけでレコードを変更しないでください。

正規ドメインでは正常なら何を直しますか？

CloudflareやWordPress本体ではなく、IP形式URLを保存している場所を直します。ブックマーク、リンク、監視、Webhook、API、リダイレクトを発生元から順に確認してください。

IPを指定して移行先サーバーを確認したい場合は？

URLのホスト名は正規ドメインのまま、接続先だけをホスティング会社が確認したオリジンIPへ向けます。共有サーバーやWAFでは制限があるため、ホスティング会社の移行確認手順を優先してください。

まとめ

Cloudflare Error 1003は、ブラウザやクライアントがCloudflare IPをURLとして直接開いたときに表示されるエラーです。公開DNSでCloudflare IPが返る通常動作、DNS Contentが禁止IPを指す1002、SNI・Host不一致の1013と分けて考えてください。

完全なURLとアクセス元を保存し、IP形式のブックマーク・リンク・監視・連携先だけを正規のHTTPSドメインへ置き換えることが安全な復旧です。正規ドメインで正常なら、DNSやWordPress本体をむやみに変更する必要はありません。

-速度改善・安全対策