Cloudflareを使っているWordPressで「Error 1006」「1007」「1008」「1106」や「Access Denied: Your IP address has been banned」が表示されたら、訪問者が使っているIPアドレスがサイト所有者側の設定で遮断されています。
WordPressのパスワードや投稿権限が直接の原因とは限りません。まず、誰が・どの回線で・いつ・どのURLを開いたときに拒否されたかを保存し、Cloudflare側の遮断条件を確認します。
最初にエラー画面全体、Ray ID、発生時刻とタイムゾーン、対象URL、分かる範囲の訪問元IPを保存してください。証拠を残さずルールを削除したり、Cloudflare全体を停止したりすると、誤遮断の原因が分からないまま防御だけが弱くなります。
先に結論：IP遮断エラーは8段階で確認する
- エラー番号、画面、Ray ID、時刻、URLを保存する
- 一人だけか、複数の利用者にも起きるかを確認する
- 同じ端末でWi-Fiと携帯回線を切り替え、回線差を診断する
- 訪問元のグローバルIPを安全に確認する
- Security Eventsを時刻、Ray ID、IP、Host、Pathで絞る
- IP Access Rules、Custom Rules、Zone Lockdownなどの原因設定を確認する
- 誤遮断なら原因条件だけを最小範囲で修正する
- 公開ページ、管理画面、フォーム、REST API、防御を再確認する
同じ通信事業者やクラウドの広い範囲が止まる1005なら、Cloudflare Error 1005のASN遮断確認手順を使います。一定時間の要求数で止まる場合は、Cloudflare Error 1015のレート制限確認手順へ進んでください。
1006・1007・1008・1106とは？
Cloudflare公式のError 1006・1007・1008・1106は、訪問元IPが禁止されているためアクセスを拒否した状態です。Cloudflareの利用者、つまりサイト所有者側の設定が、そのクライアントまたはブラウザからの通信を遮断しています。
画面に複数の番号のいずれかが出ても、基本の確認軸は同じです。「現在の訪問元IP」「発生時刻」「対象ホストとパス」「どの設定がBlockしたか」を結び付けます。エラー番号だけを見て、WordPress本体やプラグインを無関係に削除しないでください。
1005・1006系・1009・1015・1020・403の違い
| 表示 | 主な拒否理由 | 最初の確認先 |
|---|---|---|
| 1005 | 訪問元が属するASNを遮断 | ASN、IP Access Rules、Security Events |
| 1006・1007・1008・1106 | 訪問元IPを遮断 | クライアントIP、時刻、遮断設定 |
| 1009 | 国または地域を遮断 | 国条件、IP Access Rules、Custom Rules |
| 1015 | 要求回数が制限値を超過 | Rate Limiting Rules、再試行時刻 |
| 1020 | WAFなどのアクセスルールに一致 | Ray ID、Security Events、Rule |
| HTTP 403 | Cloudflareまたはオリジンが一般的に拒否 | 応答元、WAF、Webサーバー、権限 |
画面にCloudflareの番号とIP bannedが明記されていれば、個別IPの遮断を優先して調べます。番号がなく一般的な403だけなら、WordPressの403 Forbiddenを直す確認順で、Cloudflare、Webサーバー、WordPressのどこが返したかを分けます。
最初に影響範囲を切り分ける
一人だけか、同じ回線の複数人か
報告者一人だけなら、その人の現在のグローバルIPに対するBlockを疑います。同じ会社や家庭の複数端末で同時に起きる場合は、端末が共通の出口IPを使っている可能性があります。端末ごとのローカルIPではなく、インターネット側から見えるグローバルIPを確認します。
Wi-Fiと携帯回線で結果が変わるか
同じ端末・同じURLでWi-Fiから携帯回線へ切り替えて表示できるなら、回線によって変わるIPが重要な手掛かりです。ただし回線切り替えは原因を見つける診断であり、恒久対策ではありません。元の正規利用者が元の回線から使える状態へ戻す必要があります。
IPが変動していないか
家庭回線、携帯回線、VPN、会社の出口、プロキシではIPが変わることがあります。後から確認したIPと、エラー発生時のIPが同じとは限りません。エラー時刻とセットで取得し、再現のたびに記録を更新してください。
訪問者から受け取る情報
- エラー画面全体のスクリーンショット
- 1006、1007、1008、1106のどの番号か
- Ray ID、表示された時刻、タイムゾーン
- 失敗した完全なURLと直前の操作
- Wi-Fi、携帯、会社、VPNなどの回線種別
- 別回線・別端末・別ブラウザでの結果
- 発生時点のグローバルIP
- 初回発生と直近再現の時刻
IPアドレスはアクセス情報です。公開コメント欄やSNSへ貼らせず、管理者だけが確認できる連絡手段を使います。スクリーンショットにCookie、メールアドレス、管理画面の秘密情報が含まれる場合は、調査に不要な部分を隠してください。
Security Eventsと設定を照合する
Cloudflare公式のSecurity Eventsでは、セキュリティ機能が処理またはフラグ付けしたイベントを確認できます。時間範囲を合わせ、Ray ID、IP、Host、Path、Action、Serviceなどを使って該当通信を絞ります。
1. 時刻とタイムゾーンをそろえる
利用者の申告時刻、エラー画面の時刻、Cloudflareダッシュボードの時間範囲を同じ基準へそろえます。数分のずれを見込み、失敗の直前から直後までを検索します。プランにより保持期間と表示機能が異なり、Sampled logsは全通信を必ず表示するものではありません。
2. Ray IDとIPから該当通信を探す
Ray IDがあれば優先して使い、見つからない場合はIP、Host、Pathを組み合わせます。IPが変動している場合は、現在値ではなく発生時点の値が必要です。似た時刻に同じIPから複数の要求があるときは、対象URLとHTTPメソッドも比較します。
3. Action・Service・Ruleを読む
Blockされた事実だけで終わらず、どの製品・ルールが、どの条件で処理したかを確認します。同じHTTP要求が複数のセキュリティ機能へ一致すると、複数イベントとして表示されることがあります。削除済みルールが「Rule unavailable」と表示される場合は、Audit logsで変更履歴も確認します。
IP Access Rulesを確認する
Cloudflare公式のIP Access rulesは、IPアドレス、ASN、国を条件に通信を許可、遮断、チャレンジできます。報告されたIPと一致するBlockがないか、IPv4・IPv6の別、適用先のゾーンまたはアカウント、作成理由、関連する障害対応記録を確認します。
変更前に、対象値、Action、適用範囲、作成日時、メモを保存します。攻撃対応で意図的に追加したBlockなら、正規利用者から一件報告があっただけで即削除せず、同じIPからの不正通信、必要なアクセス先、代替できる狭い条件を比較します。
Custom Rulesなど他の設定も確認する
IP Access Rulesに一致する項目がなければ、Custom Rules、Zone Lockdown、User Agent Blocking、Browser Integrity Checkなど、該当時刻に通信を拒否した設定をイベント情報からたどります。名称だけで判断せず、実際に一致したフィールドと条件式を確認してください。
Cloudflare公式には、WorkersのPreviewタブが利用するGoogle Cloud PlatformのIPをZone Lockdownなどで遮断した場合にも1006が起きるとの注記があります。通常の訪問者ではなくPreviewだけが失敗するなら、公開サイトの障害と決め付けず、Previewの通信元と対象ゾーンの制限を確認します。
WAFなどの一般的なルール一致として1020が出ている場合は、Cloudflare Error 1020のRay ID確認手順で原因ルールを切り分けてください。
安全な修正方法
明らかな誤登録ならBlockを訂正する
IPの入力間違い、検証用ルールの消し忘れ、期限切れの一時対策など、誤設定と確認できた場合は変更前を保存して訂正します。修正後のアクセスでは新しいRay IDと時刻を記録し、前後を比較します。
攻撃対策なら条件を狭める
同じIPから不正通信と正規通信が混在する場合は、Host、Path、HTTPメソッド、認証済み状態、検証できるサービス署名などを組み合わせ、必要な通信だけを扱えるか検討します。User-AgentやRefererだけは変更・偽装され得るため、それだけを信頼条件にしません。
固定IPの外部サービスは公式情報で確認する
監視、決済、Webhook、API、検索クローラーなどが止まった場合は、そのサービスの公式な送信元IP、署名、認証方式、更新通知を確認します。利用者から送られたIPだけを無期限に許可するのではなく、サービス側が保証する条件と更新運用まで決めます。
IP全体をAllowにする前の注意
Cloudflare公式は、IP Access RulesのAllowがCustom Rules、Rate Limiting Rules、WAF Managed Rulesなど複数の防御を迂回すると注意しています。エラーを早く消すためにAllowへ反転すると、同じIPからの不正通信まで広く通すおそれがあります。
復旧のゴールはエラー画面だけを消すことではなく、必要な正規通信を戻し、関係のない防御を残すことです。原因Blockの訂正、条件の限定、目的に合うCustom RuleやSkipの検討を優先し、無条件のAllowは最後まで影響範囲を確認してください。
やってはいけない対処
- 原因確認前にCloudflareプロキシやWAFを全面停止する
- エラー画面と時刻を保存せずBlockを削除する
- 報告されたIPを無条件・無期限でAllowにする
- 別回線で開けたことだけで解決扱いにする
- VPNを何度も切り替えて調査対象IPを増やす
- 公開コメントやSNSで利用者のIPを集める
- 無関係なWordPressユーザー、テーマ、プラグインを削除する
- 攻撃状況を確認せず一時対策をすべて解除する
修正後に確認すること
- 報告者の元の回線からエラーが消えた
- 別回線と別端末でも公開ページを表示できる
- トップ、投稿、固定ページ、カテゴリー、検索、404が正常
- 管理画面へログインし、保存とプレビューができる
/wp-json/と必要なREST APIが正常- フォーム、決済、Webhook、監視が正常
- 画像、CSS、JavaScript、サイトマップを取得できる
- Security Eventsで同じ誤遮断が再発していない
- Custom Rules、Rate Limiting、Managed Rulesが必要どおり動く
- 1006系が1005、1009、1015、1020、403へ変わっていない
直らないときの確認順
修正したのに同じ表示が続く場合は、正しいゾーンを変更したか、アカウントとゾーンの別設定に同じIPが残っていないか、IPv4とIPv6のどちらで再接続したかを確認します。ブラウザに残った古い画面ではなく、新しいアクセスのRay IDと時刻で判断してください。
Cloudflare Supportへ相談する場合でも、サイト訪問者ではなくサイト所有者が問い合わせます。エラー画面、Ray ID、UTCとローカル時刻、対象URL、発生時点のIP、Action・Service・Rule、変更前後の設定、再現結果をまとめると引き継ぎやすくなります。
よくある質問
ブラウザのCookieを消せば直りますか？
IP遮断が原因なら、Cookie削除だけでは通常解決しません。ただし同じ操作を再現する前に、回線、IP、時刻、URLを記録し、別ブラウザとの差は補助情報として使えます。
携帯回線では開けるので放置してよいですか？
放置はおすすめしません。Wi-Fi側のIPに誤ったBlockがある可能性が残ります。攻撃対策として正しい遮断なのか、正規利用者を巻き込んだのかを所有者側で確認してください。
同じ会社の全員が止まるのは個別IP遮断ですか？
会社の端末が共通の出口IPを使っていれば、個別IPのBlockでも全員へ影響します。複数IPやASN全体が対象なら1005など別の原因も考え、各利用者の発生時IPとエラー番号を比較します。
まとめ
Cloudflare Error 1006・1007・1008・1106は、訪問元IPがサイト所有者側の設定で遮断されているときのエラーです。エラー画面、Ray ID、時刻、URL、発生時点のIPを保存し、Security Eventsと実際の遮断設定を照合します。
別回線は診断にだけ使い、Cloudflare全停止や無条件Allowで済ませないでください。誤遮断の原因条件だけを最小範囲で直し、公開表示、管理画面、REST API、フォーム、外部連携と必要な防御が両立したことまで確認します。