Cloudflareを利用しているWordPressで「Error 1012: Access Denied」と表示されたら、サイト所有者側が、訪問者の端末またはネットワークから検知された不審な活動を理由にアクセスを拒否しています。
このエラーでは、WordPressのパスワード変更やプラグイン停止より先に、利用者側の端末・回線の安全確認と、運営者側の遮断記録の照合を分けて進めます。サイトが攻撃されたとも、利用者の端末が感染したとも、エラー番号だけでは確定できません。
最初にエラー画面全体、発生時刻とタイムゾーン、完全なURL、Ray ID、発生時のグローバルIPを保存してください。証拠を残す前にWAFを停止したり、報告されたIPを無条件でAllowしたりすると、原因を失ったまま防御だけが弱くなります。
先に結論：Error 1012は8段階で確認する
- 1012の画面、Ray ID、時刻、URL、発生時IPを保存する
- 一人だけか、同じ回線の複数端末でも起きるかを確認する
- 利用者のOS、ブラウザー、セキュリティ機能を更新する
- 信頼できるセキュリティ製品で端末をフルスキャンする
- 管理された条件で別端末・別回線を一度だけ比較する
- 運営者はSecurity Eventsと遮断ルールを照合する
- 正規通信と確認できた場合だけ原因ルールを最小修正する
- 復旧後も主要機能と防御の再動作を確認する
エラー画面に「Your IP address has been banned」と表示される場合は、Cloudflare Error 1006系のIP遮断確認手順を使います。要求回数が増えたときだけ止まる場合は、Cloudflare Error 1015のレート制限確認手順へ進んでください。
Error 1012とは？
Cloudflare公式のError 1012は、訪問者のコンピューターまたはネットワークから悪意のある活動が検知されたことを理由に、サイト所有者がアクセスを禁止した状態と説明されています。Cloudflare側の一時障害ではなく、所有者側のセキュリティ判断による拒否です。
公式資料は「最も可能性の高い原因」として、訪問端末のウイルスまたはマルウェア感染を挙げています。ただし、これは感染の確定診断ではありません。共有回線の別端末、不正な拡張機能、侵害されたルーター、VPNやプロキシの出口IP、正規ツールの異常な通信なども含め、端末とネットワークを調べます。
1012・1006系・1010・1020・403の違い
| 表示 | 主な意味 | 最初の確認 |
|---|---|---|
| 1012 | 端末・ネットワークの不審な活動を理由とする拒否 | 端末の安全、発生時IP、所有者側の遮断 |
| 1006・1007・1008・1106 | 訪問元IPが禁止されている | IP Access Rules、発生時IP |
| 1010 | ブラウザー署名を理由とする拒否 | BIC、User-Agent |
| 1020 | WAF等のルール条件による拒否 | Ray ID、Service、Rule |
| HTTP 403 | Cloudflareまたはオリジンの一般的な拒否 | 応答元、WAF、サーバー、権限 |
ブラウザー署名が原因なら、Cloudflare Error 1010とBICの確認手順が合います。一般的な「Access Denied」で1020が表示される場合は、Cloudflare Error 1020の確認手順を使ってください。Cloudflare固有番号がない403は、WordPressの403 Forbiddenを直す手順で応答元を切り分けます。
最初に保存する情報
- エラー画面全体と「Error 1012」の文言
- Ray IDが表示されている場合はその値
- 発生時刻とタイムゾーン
- 失敗した完全なURLと直前の操作
- 発生時のグローバルIP
- 端末、OS、ブラウザーの名称とバージョン
- VPN、プロキシ、セキュリティ製品の利用有無
- 同じ回線の別端末、別回線、別利用者での結果
- 初回発生と直近再現の時刻
IPアドレスは後で変わることがあり、家庭・会社・携帯回線では複数人が同じ出口IPを共有することもあります。「現在のIP」ではなくエラー発生時のIPを記録してください。スクリーンショットにIPやRay IDが写る場合は、公開SNSへそのまま載せず、運営者の安全な窓口で共有します。
利用者側で先に行う安全確認
1. OS・ブラウザー・セキュリティ製品を更新する
Windows Update、macOSやスマートフォンのシステム更新、ブラウザー更新を完了し、導入済みの信頼できるウイルス対策ソフトも最新状態にします。更新元はOSまたは製品の公式機能に限定し、エラー画面から誘導される不明な「駆除ツール」を入れないでください。
2. フルスキャンを実行する
Cloudflare公式の案内どおり、ウイルス対策を更新してフルシステムスキャンを行います。簡易スキャンだけでなく、可能なら起動領域、常駐項目、ブラウザー拡張機能も確認します。検出があった場合は、製品の正式な隔離・削除手順に従い、重要アカウントのパスワード変更は端末の安全を確保した後に行います。
3. 不要な拡張機能と常駐アプリを確認する
身に覚えのないブラウザー拡張機能、広告挿入ツール、無料VPN、非公式ダウンローダー、古いリモート管理ソフトがないか確認します。無効化と削除は同じではありません。提供元、導入日、権限を記録し、業務端末なら管理担当者へ連絡してから変更してください。
4. ルーターと共有回線も疑う
同じWi-Fiの複数端末で1012になるのに、携帯回線では開ける場合は、共有の出口IP、ルーター、または同じネットワーク内の別端末が関係している可能性があります。ルーターのファームウェア更新、管理パスワード、DNS設定、見覚えのない接続端末を確認します。会社や学校の回線は自分で設定を変えず、管理者へ時刻・URL・IPを渡してください。
別端末・別回線の比較方法
比較は原因を絞るために一度ずつ行います。同じ端末を別回線へ接続する、同じ回線で別端末を使う、最新の通常ブラウザーで開く、という順なら「端末」「回線」「ブラウザー」のどこで結果が変わるか追いやすくなります。
| 比較結果 | 疑う範囲 | 次の行動 |
|---|---|---|
| 同じ端末は別回線でも1012 | 端末、ブラウザー、常駐ソフト | 更新、フルスキャン、拡張機能確認 |
| 同じ回線の複数端末で1012 | 出口IP、ルーター、共有端末 | ネットワーク管理者へ連絡 |
| 特定ブラウザーだけ1012 | 拡張機能、要求ヘッダー | 1010やBICの記録も照合 |
| 複数の無関係な利用者で1012 | 所有者側の広い遮断条件 | 運営者がルール範囲を監査 |
VPNを切り替えて何度もIPを変え、遮断を回避し続ける方法は使わないでください。調査用の比較は管理された環境で一度だけ行い、結果とIPを記録します。正規利用者でも、出口IPを次々変える挙動は追加の防御に触れることがあります。
サイト運営者が確認する順番
1. 本当に1012かを確認する
利用者の説明だけで判断せず、画面全体でError 1012を確認します。Ray ID、時刻、URL、IPを受け取り、トップページだけか、ログイン、フォーム、REST APIなど特定の経路だけかも記録します。番号が違えば確認先も変わります。
2. Security Eventsを時刻とIPで絞る
Cloudflare公式のSecurity Eventsでは、セキュリティ製品が処理またはフラグ付けしたイベントを調査できます。対象ゾーンを選び、発生時刻の前後を狭くし、IP、Host、Path、User Agent、Action、Serviceを確認します。
Security Eventsには保持期間があり、プランによって期間が異なります。また、サンプリングにより個別イベントが必ず表示されるとは限りません。報告を受けたら早めに確認し、見つからないことだけで「Cloudflareは関係ない」と断定しないでください。
3. IP Access RulesとCustom Rulesを監査する
IP Access Rules、WAF Custom Rules、レート制限、User Agent Blocking、外部の脅威情報を取り込む仕組み、過去の緊急遮断を確認します。ゾーン単位だけでなく、アカウント単位のルールやホスティング側のファイアウォールも対象です。ルール名、条件、Action、作成者、変更日時を記録します。
4. 同じIPの成功・失敗を比較する
同じIPから直前まで正常だったか、同じURL以外には到達できるか、失敗時のUser-Agentやメソッドに偏りがあるかを確認します。共有IPでは一人の正規利用者と別端末の不審な通信が同居することがあります。IPだけを本人確認として扱わないでください。
正規利用者だけを安全に復旧する
原因が端末なら、先に端末を正常化する
マルウェアや不審な拡張機能が見つかった場合は、隔離・削除、更新、再スキャンを完了してから再接続します。感染の疑いを残したままIPだけ許可すると、サイトだけでなく利用者の認証情報や他サービスにも影響が及ぶ恐れがあります。
誤遮断なら、Blockの原因だけを修正する
正規通信と確認でき、既存のIP Blockや外部連携の誤登録が原因なら、該当する条件だけを削除・修正します。変更前後の設定と時刻を残し、別の防御機能まで同時に変えません。可能ならBlockからChallengeへ緩和するなど、必要な検査を残せる方法を検討します。
Allowより狭い条件を優先する
Cloudflare公式のIP Access Rulesでは、IPまたはASNをAllowするとCustom Rules、Rate Limiting Rules、Managed Rulesなどを回避します。正規利用者一人のために、共有IPやASN全体へ広いAllowを作るのは危険です。専用の認証済み経路、必要なHost・Path・メソッド、既知の送信元などを組み合わせ、対象を最小化します。
Cloudflareへ問い合わせる前にそろえるもの
Cloudflare公式は、所有者が設定したセキュリティをCloudflare Supportが上書きできないと案内しています。まずサイト運営者が自分の設定と記録を確認します。それでも原因を特定できない場合は、対象ゾーン、Error 1012の画面、Ray ID、UTCを含む発生時刻、URL、発生時IP、再現条件、確認済みルール、変更履歴をそろえます。
利用者がCloudflareへ直接依頼しても、サイト所有者の設定を解除してもらうことはできません。利用者は端末・回線の安全確認を済ませたうえでサイトの問い合わせ窓口へ連絡し、運営者が必要に応じてCloudflareへ問い合わせます。
やってはいけない対処
- 1012だけで利用者を攻撃者、または感染者と断定する
- 証拠を保存せずWAFやCloudflareを全面停止する
- 報告されたIP、共有IP、ASNを無条件でAllowする
- VPNで出口IPを変え続けて遮断を回避する
- 出所不明の駆除ツールやブラウザー拡張機能を入れる
- 業務端末のセキュリティ製品を無断で恒久停止する
- 複数の遮断ルールを同時に変更する
- 別回線で開けたことだけで端末の安全確認を終える
- 無関係なWordPressユーザー、テーマ、プラグインを削除する
修正後の確認項目
- 問題の正規利用者から1012が消えた
- 端末の更新とフルスキャンが完了した
- 同じ回線の他端末に不審な状態がない
- トップ、投稿、固定ページ、カテゴリー、検索、404が正常
- 管理画面のログイン、保存、プレビューが正常
- フォーム、REST API、Webhook、監視、RSSが正常
- 対象外のIP・経路ではWAFとレート制限が動作している
- 広いAllowや一時的な全停止が残っていない
- Security Eventsで同じ誤遮断が再発していない
- 変更者、変更理由、復旧時刻、戻し方を記録した
まとめ
Cloudflare Error 1012は、訪問者の端末またはネットワークから検知された不審な活動を理由に、サイト所有者側がアクセスを拒否した状態です。公式が挙げるウイルス・マルウェア感染の可能性を軽視せず、同時にエラーだけで感染を断定もしないことが大切です。
利用者は端末の更新とフルスキャン、運営者は時刻・IP・Ray ID・ルールの照合を先に行い、正規通信と確認できた範囲だけを復旧してください。防御全体を止めず、原因となった一条件を直すことが、安全で再発を追える解決です。