Cloudflareを利用しているWordPressで「Error 1020: Access Denied」と表示され、自分のサイトなのに閲覧、ログイン、投稿保存ができなくなることがあります。特定の回線、海外、VPN、管理画面、REST APIだけが拒否されるケースもあります。
Error 1020は、Cloudflare側のセキュリティルールがアクセスを拒否したことを示します。WordPressのパスワード間違いやサーバーダウンとは発生層が違います。画面のRay IDと発生時刻を手掛かりに、Security Eventsで実行されたルールを探します。
WAF全体を停止したり、自分のIPを無条件で永久許可したりしないでください。攻撃防御まで弱くなり、動的IPでは後日別の利用者へ許可が移る可能性もあります。拒否した条件を特定し、必要な範囲だけを修正します。
先に結論：Error 1020は8段階で確認する
- 拒否されたURL、画面、Ray ID、時刻、タイムゾーンを保存する
- 別回線や別端末で再現範囲を確認する
- CloudflareのSecurity Eventsを同じ時刻とRay IDで検索する
- 実行したルール、アクション、送信元IP、パスを特定する
- 正当なアクセスか、攻撃・自動化・誤設定かを判断する
- ホスト、パス、操作、IPなど必要最小範囲でルールを修正する
- 同じ操作と防御テストの双方を確認する
- WordPress、ログ、検索への影響と再発を確認する
1020は403系の拒否画面として現れますが、一般的な403すべてが1020ではありません。Cloudflareの番号がなく、WordPress、Webサーバー、ファイル権限が原因の可能性がある場合は、WordPressの403 Forbiddenを直す確認順で発行元を分けてください。
Cloudflare Error 1020とは？
Cloudflare公式のError 1020では、Cloudflareのファイアウォールルールによりアクセスが拒否された状態と説明されています。訪問者は画面をサイト所有者へ送り、所有者はRay IDまたはクライアントIPでSecurity Eventsを確認します。
要求はCloudflareまで到達していますが、拒否アクションに一致したため、WordPressサーバーへ転送されない場合があります。そのためWordPressのアクセスログに同じ要求が見つからなくても不思議ではありません。Cloudflare側の記録から確認します。
Ray IDはCloudflareが個々の要求を追跡するための識別情報です。画面下部に表示される値と発生時刻を保存すると、似たアクセスが多い時間帯でも対象イベントを絞りやすくなります。時刻には日本時間かUTCかも添えます。
1020・一般的な403・401・429の違い
| 表示 | 主な意味 | 最初に見る場所 |
|---|---|---|
| Cloudflare 1020 | セキュリティルールが拒否 | Ray ID、Security Events、実行ルール |
| 403 Forbidden | 権限・WAF・サーバーなど幅広い拒否 | 発行元、ヘッダー、サーバーログ |
| 401 Unauthorized | 必要な認証がない・無効 | 認証方式、資格情報、WWW-Authenticate |
| 429 Too Many Requests | 一定時間内の要求が多すぎる | 発行元、Rate Limiting、Retry-After |
ログイン情報が求められる401ならWordPressの401 Unauthorizedを直す確認順、アクセス頻度で429になるならWordPressの429を安全に確認する手順を使います。番号を混同すると、防御ルールを不要に緩めることになります。
WordPressでError 1020が出る主な原因
1．IP・国・ASNの条件が正当な利用者にも一致した
特定国を遮断するルール、データセンターASNを拒否するルール、過去の攻撃IPを止めるリストなどに、正当なアクセスが含まれています。VPN、携帯回線、会社回線では出口IPや国判定が普段と変わるため、自分だけ突然拒否されることがあります。
2．管理画面やログインURLの保護条件が厳しすぎる
`/wp-admin/`や`/wp-login.php`を特定IPだけに制限していると、回線変更や動的IPの更新後に管理者自身が拒否されます。ログイン保護は有効ですが、固定IPの前提、バックアップ認証経路、緊急時の解除手順まで用意する必要があります。
3．URI・クエリ・User-Agent条件が広すぎる
不審な文字列を含むURL、空のUser-Agent、長いクエリなどを止める自作ルールが、WordPressのプレビュー、検索、フォーム、管理画面のパラメータにも一致する場合があります。条件の一部だけを見るのではなく、実際に一致した式全体を確認します。
4．REST APIや外部連携を自動アクセスとして拒否した
ブロックエディター、モバイルアプリ、バックアップ、決済、フォーム、外部公開ツールはREST APIやWebhookを利用します。ブラウザのページ表示は正常でも、`/wp-json/`や特定のPOST要求だけがセキュリティ条件に一致し、保存や連携だけ失敗することがあります。
5．旧Firewall Rulesが残っている
Cloudflare公式はError 1020の一般的な原因として、現在は非推奨となったFirewall Rulesを挙げています。新しいWAFカスタムルールだけを確認しても、移行前のルールやIP Access Rulesが別に残っている場合があります。
6．複数ルールの優先順位や例外が意図と違う
許可ルールを作ったつもりでも、別の拒否ルールが先に実行される、例外対象のホストやパスが不足するなど、評価順で結果が変わることがあります。個々のルール名だけではなく、対象要求に最終的にどのアクションが実行されたかを確認します。
7．共有IPの悪用履歴に巻き込まれた
会社、学校、ホテル、VPN、携帯回線などは、一つの公開IPを多くの利用者で共有します。同じIPから攻撃や大量アクセスがあった場合、正当な利用者もIP条件に一致します。IP全体の永久許可ではなく、認証や対象パスを組み合わせた例外を検討します。
訪問者が管理者へ送る情報
- Error 1020の画面全体が分かるスクリーンショット
- エラーが出た完全なURL
- 画面下部のCloudflare Ray ID
- 発生日時、タイムゾーン
- 行おうとした操作
- 常時か、特定ページ・操作だけか
- VPN利用の有無と回線種別
- 可能なら別回線で再現したか
パスワード、Cookie、認証トークン、フォームに入力した個人情報は送らないでください。URLに機密情報が含まれる場合は、管理者と安全な共有方法を決めます。公開SNSへRay IDと詳細設定をまとめて投稿する必要もありません。
Ray IDとSecurity Eventsで一致する記録を探す
サイト所有者はCloudflareダッシュボードのSecurity Eventsを開き、エラー時刻の前後を対象にします。Cloudflare公式のSecurity Events資料では、サービス、送信元、アクション、ホスト、国、パス、IP、User-Agent、ASNなどでイベントを確認できると説明されています。
まずRay IDで検索し、見つからない場合はクライアントIP、ホスト、パス、発生時刻を組み合わせます。訪問者の時刻が日本時間で、Cloudflare画面がUTC表示なら時差を合わせます。数分のずれも考慮します。
| 見る項目 | 確認内容 | 判断例 |
|---|---|---|
| Action | Blockなど実行された処理 | 本当に拒否イベントか |
| Service・Rule | どの機能・ルールが実行したか | 自作WAF、旧ルール、IP制限 |
| Host・Path | 拒否された対象範囲 | 管理画面だけ、APIだけ |
| Source IP・ASN・Country | 送信元の特徴 | VPN、共有回線、地域判定 |
| User-Agent・Method | ブラウザやPOSTなどの種類 | 外部連携だけ一致 |
イベントが見つかったら、ルールをすぐ削除せず、何を防ぐために作られたかを確認します。正当な要求と攻撃要求の違いを、ホスト、パス、HTTPメソッド、認証済みの経路、送信元などで表現できるかを検討します。
原因別の安全な直し方
1．該当ルールの式と目的を確認する
Security Eventsに表示されたルールを開き、ホスト、パス、IP、国、ASN、User-Agent、メソッドなど、どの条件が一致したかを読みます。ルール名だけで判断せず、正当なアクセスまで含む条件になっていないか確認します。
2．例外を対象ホスト・パス・操作へ限定する
管理画面の特定APIだけ許可したいなら、サイト全体やIP全体ではなく、必要なホスト、パス、HTTPメソッドに絞ります。例外を作る場合も、別の認証やログイン保護が効いていることを確認します。
3．動的IPを永久許可しない
家庭や携帯回線のIPは変わるため、現在のIPを永久許可すると、後日その値を割り当てられた別人も通る可能性があります。固定IPを使う、Cloudflare Accessなど認証手段を使う、短期の変更として期限と見直し日を記録する方法を検討します。
4．外部サービスの送信元と仕様を公式情報で確認する
決済、フォーム、バックアップなどを許可する場合は、サービス公式が公開する送信元IP、署名検証、Webhook URLを確認します。検索で見つけた古いIP一覧や、広い国・ASN単位の許可で代用しません。
5．ルール変更後も攻撃要求が止まることを確認する
正当な操作が通るだけでは確認不足です。変更前に防いでいた不審パス、異常メソッド、対象外ホストなどが引き続き拒否されることも確認します。防御テストは本番へ負荷をかけず、少数の安全な要求で行います。
6．旧ルールとIP Access Rulesを整理する
同じ目的のルールが新旧で重複している場合は、各ルールの所有者、最終更新、対象範囲を記録します。使っていないと確認できたものだけを、バックアップまたは変更履歴を残して整理します。
やってはいけない対処
- CloudflareのWAFとセキュリティ機能をすべて停止する
- 原因確認なしにIP、国、ASN全体を永久許可する
- Ray IDと発生時刻を保存せずルールを削除する
- 複数ルールを同時に変更して復旧理由を不明にする
- WordPressのパスワード変更だけを繰り返す
- 動的IPを固定IPだと思い込む
- Webhookの署名検証を外して通す
- Cookie、トークン、個人情報をサポート掲示板へ貼る
1020が消えたことだけを成功条件にすると、防御を解除しただけでも復旧に見えます。「正当なアクセスは通る」「本来止める要求は止まる」の二つを必ず確認してください。
復旧後の確認項目
- 問題のURLと操作が元の回線で正常になる
- 別回線、ログアウト状態、スマートフォンでも意図どおり
- WordPressログイン、保存、プレビュー、画像アップロードが動く
- REST API、フォーム、Webhook、外部連携が動く
- 不審アクセスへのBlockがSecurity Eventsに残る
- 例外の対象が必要なホスト・パス・操作だけ
- 変更者、理由、日時、元の式を記録した
- 一定時間後も1020が再発しない
ログインだけが問題だった場合は、WordPress管理画面へ入れないときの確認手順も使い、Cloudflare復旧後にCookie、認証、プラグインなどWordPress側の残りを切り分けます。
検索への影響とGooglebotの扱い
GoogleのHTTPステータス資料では、404以外を含む4xx応答はコンテンツをインデックスしない扱いになり、既存URLも時間とともにインデックスから外れ得ると説明されています。実際のHTTPステータスと継続期間を確認します。
Googlebotを誤って拒否していた可能性がある場合も、User-Agent文字列だけで無条件許可しないでください。偽装可能だからです。Googleの公式な確認方法とCloudflareの検証済みボット機能を使い、Security Eventsで実行ルールを確認します。
復旧後はSearch Consoleで主要URLのURL検査、ページのインデックス登録、クロール統計を確認します。短時間の単発なら慌ててサイト全体を再送信せず、重要ページから正常応答と再クロールを確認します。
それでも直らないときの問い合わせ情報
- 対象URL、行った操作、Error 1020の画面
- Ray ID、発生時刻、タイムゾーン
- 送信元IP、回線、VPNの有無
- Security Eventsの一致イベントと実行ルール
- 対象ホスト、パス、メソッド、User-Agent
- 直前に変更したWAF・IP・国・ASNルール
- 別回線・別端末での再現結果
- 認証情報を除いた関係ログ
訪問者はサイト管理者へ、サイト管理者は必要に応じてCloudflareへ連絡します。訪問者側からCloudflareへ依頼しても、サイト所有者のセキュリティルールを変更することはできません。
よくある質問
自分のサイトなのにブロックされるのはなぜですか？
CloudflareはWordPressの管理者かどうかではなく、要求時点のIP、国、パス、メソッドなどでルールを評価します。管理者でも、VPNや動的IP、管理画面のパスが条件に一致すれば拒否されます。
Cookie削除やブラウザ変更で直りますか？
要求の特徴が変わって一時的に通る場合はありますが、根本原因はセキュリティルールです。Ray IDとSecurity Eventsで該当ルールを確認しなければ、同じ操作で再発する可能性があります。
WordPressのデバッグログに何もないのは異常ですか？
Cloudflareで拒否され、要求がオリジンへ届かなければWordPressログに残らないことがあります。1020を解消した後もWordPress側で失敗する場合に限り、WordPress公式のデバッグ手順で安全にログを確認します。
IP許可は何分だけなら安全ですか？
時間だけで一律に安全とは言えません。IPが固定か、共有か、何を許可するかで変わります。必要なら期限、対象パス、作業者、削除時刻を決め、作業後に必ず元へ戻します。
まとめ
Cloudflare Error 1020は、Cloudflareのセキュリティルールが要求を拒否したサインです。訪問者はURL、画面、Ray ID、時刻を管理者へ送り、管理者はSecurity Eventsで一致イベントと実行ルールを確認します。
WAF全停止や広すぎるIP許可で消すのではなく、正当な要求と攻撃要求の違いを特定し、必要なホスト・パス・操作だけを最小修正してください。復旧後も防御が働くことまで確認して、はじめて安全な解決です。